D - DMD Bug: Module names not being used in internal symbols.
- Burton Radons (9/9) Jul 25 2003 The lack of proper mangling in internal symbols has been a problem the
- Charles Sanders (10/109) Jul 25 2003 Can we expect TreeCtrl and ListCtrl in the next dig release ?
- Burton Radons (11/12) Jul 25 2003 ListBox has been in since 0.0.10, although it's not completed or really
- Matthew Wilson (2/11) Jul 25 2003 Label. Let the namespace sort it out.
- Walter (1/1) Jul 26 2003 Ok!
- Burton Radons (8/8) Jul 26 2003 Since you'll be in mangling anyway, could you fix symbol mangling to use...
- Walter (5/12) Jul 26 2003 Sounds good.
The lack of proper mangling in internal symbols has been a problem the entire time I've been with D, well over a year. Get with it, Walter. Attached shows a trigger for some of them and the response from DMD, although I couldn't figure out how to trigger "_array_<modulename>". There's even some new ones in "new" and "delete"! There's no excuse to put such an easily avoided bug in the compiler now. I can't release, or even finish, the next version of dig without this and path preservation (Preserving paths in .obj files) being released, so I'd appreciate it if 0.69 were to come soon after.
Jul 25 2003
Can we expect TreeCtrl and ListCtrl in the next dig release ? Charles "Burton Radons" <loth users.sourceforge.net> wrote in message news:bfruug$pmg$1 digitaldaemon.com...The lack of proper mangling in internal symbols has been a problem the entire time I've been with D, well over a year. Get with it, Walter. Attached shows a trigger for some of them and the response from DMD, although I couldn't figure out how to trigger "_array_<modulename>". There's even some new ones in "new" and "delete"! There's no excuse to put such an easily avoided bug in the compiler now. I can't release, or even finish, the next version of dig without this and path preservation (Preserving paths in .obj files) being released, so I'd appreciate it if 0.69 were to come soon after.---------------------------------------------------------------------------- ----C:\>dmd f.d g.d c:\dmd\bin\..\..\dm\bin\link.exe f+g,,,user32+kernel32/noi; OPTLINK (R) for Win32 Release 7.50B1 Copyright (C) Digital Mars 1989 - 2001 All Rights Reserved g.obj(g) Offset 001F7H Record Type 0091 Error 1: Previous Definition Different : __init_name_foo g.obj(g) Offset 00381H Record Type 0091 Error 1: Previous Definition Different : __init_name_bar g.obj(g) Offset 00397H Record Type 0091 Error 1: Previous Definition Different : __Class_name_bar g.obj(g) Offset 003ACH Record Type 0091 Error 1: Previous Definition Different : __vtbl_name_bar g.obj(g) Offset 003C3H Record Type 0091 Error 1: Previous Definition Different : __ModuleInfo_name g.obj(g) Offset 003C5H Record Type 00C3 Error 1: Previous Definition Different : _Dname__staticCtor_FZv g.obj(g) Offset 003D5H Record Type 00C3 Error 1: Previous Definition Different : _Dname__staticDtor_FZv g.obj(g) Offset 003E5H Record Type 00C3 Error 1: Previous Definition Different : _Dname_bar_new_FkZPv g.obj(g) Offset 003F7H Record Type 00C3 Error 1: Previous Definition Different : _Dname_bar_delete_FPvZv g.obj(g) Offset 00407H Record Type 00C3 Error 1: Previous Definition Different : _Dname_bar__ctor_FZC8name_bar g.obj(g) Offset 00436H Record Type 00C3 Error 1: Previous Definition Different : _Dname_bar__dtor_FZv g.obj(g) Offset 00454H Record Type 00C3 Error 1: Previous Definition Different : _Dname_bar__staticCtor_FZv g.obj(g) Offset 00464H Record Type 00C3 Error 1: Previous Definition Different : _Dname_bar__staticDtor_FZv g.obj(g) Offset 00474H Record Type 00C3 Error 1: Previous Definition Different : _Dname_bar__invariant_FZv g.obj(g) Offset 00484H Record Type 00C3 Error 1: Previous Definition Different : _Dname_bar_staticFunction_FZv g.obj(g) Offset 005AAH Record Type 00C3 Error 1: Previous Definition Different : __modctor_name g.obj(g) Offset 005D2H Record Type 00C3 Error 1: Previous Definition Different : __moddtor_name g.obj(g) Offset 005FAH Record Type 00C3 Error 1: Previous Definition Different : _assert_name --- errorlevel 18---------------------------------------------------------------------------- ----module firstPackage.name; struct foo { } unittest { } static this () { assert (1); } static ~this () { } class bar { new (uint size) { return null; } delete (void *data) { } this () { } ~this () { } static this () { } static ~this () { } invariant { } static void staticFunction () { } } void main () { }---------------------------------------------------------------------------- ----module secondPackage.name; struct foo { } unittest { } static this () { assert (1); } static ~this () { } class bar { new (uint size) { return null; } delete (void *data) { } this () { } ~this () { } static this () { } static ~this () { } invariant { } static void staticFunction () { } }
Jul 25 2003
Charles Sanders wrote:Can we expect TreeCtrl and ListCtrl in the next dig release ?ListBox has been in since 0.0.10, although it's not completed or really documented; I'll work on it. For a tree control I've been vacillating between whether to make it a subclass of ListBox or a completely separate class. Suggestions would be very valuable to me. dig's development has been hermetic, which is bound to encourage obscure features or directions people don't agree with. For example, would you prefer LabelControl over Label? I'd never use an abbreviation, but this much doesn't bother me, and if it's a win for many people I'll make the change. Oh, and which library are you using to get the menu in DIDE?
Jul 25 2003
"Matthew Wilson" <matthew stlsoft.org> ListBox has been in since 0.0.10, although it's not completed or really documented; I'll work on it. For a tree control I've been vacillating between whether to make it a subclass of ListBox or a completely separate class.Instinct says separateSuggestions would be very valuable to me. dig's development has been hermetic, which is bound to encourage obscure features or directions people don't agree with. For example, would you prefer LabelControl over Label? I'd never use an abbreviation, but this much doesn't bother me, and if it's a win for many people I'll make the change.Label. Let the namespace sort it out.
Jul 25 2003
Since you'll be in mangling anyway, could you fix symbol mangling to use
numeric prefixes? Rather than:
_Dfoo_barbaz_i
It should be:
_D3foo_6barbaz_i
I'd also like it if D symbols didn't use an underline but just started
with D. Then I don't have to guess about the nature of a variable.
I've attached files for inducing lots more of them.
Jul 26 2003
"Burton Radons" <loth users.sourceforge.net> wrote in message news:bfv543$t04$1 digitaldaemon.com...Since you'll be in mangling anyway, could you fix symbol mangling to use numeric prefixes? Rather than: _Dfoo_barbaz_i It should be: _D3foo_6barbaz_iSounds good.I'd also like it if D symbols didn't use an underline but just started with D. Then I don't have to guess about the nature of a variable.? The _D prefix makes it much less likely to have a collision with C functions.
Jul 26 2003