www.digitalmars.com         C & C++   DMDScript  

D - DMD Bug: Module names not being used in internal symbols.

reply Burton Radons <loth users.sourceforge.net> writes:
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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
next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
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
parent reply Burton Radons <loth users.sourceforge.net> writes:
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
parent "Matthew Wilson" <matthew stlsoft.org> writes:
 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 separate
 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.

Label. Let the namespace sort it out.
Jul 25 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
Ok!
Jul 26 2003
parent reply Burton Radons <loth users.sourceforge.net> writes:
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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
parent "Walter" <walter digitalmars.com> writes:
"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_i

Sounds 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