www.digitalmars.com         C & C++   DMDScript  

D - [BUG] extern (C) behavior changed in v0.81

reply "Kris" <someidiot earthlink.net> writes:
Pre v0.81 this would link correctly:

class Token
{
    extern (C) int memcmp (void *, void *, uint);

    void test()
   {
    memcmp (..., ..., ...);
   }
}

with v0.81, the linker fails with:

Error 42: Symbol Undefined __D5hello5Token6memcmpUPvPvkZi

If I move the extern (C) declaration outside of the class definition (up to
the global scope) it links correctly:

extern (C) int memcmp (void *, void *, uint);

class Token
{
    void test()
   {
    memcmp (..., ..., ...);
   }
}

Was this an intended change of symbol naming?
Mar 23 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <c3ptjf$1tg5$1 digitaldaemon.com>, Kris says...
Pre v0.81 this would link correctly:

class Token
{
    extern (C) int memcmp (void *, void *, uint);

    void test()
   {
    memcmp (..., ..., ...);
   }
}

with v0.81, the linker fails with:

Error 42: Symbol Undefined __D5hello5Token6memcmpUPvPvkZi

If I move the extern (C) declaration outside of the class definition (up to
the global scope) it links correctly:

extern (C) int memcmp (void *, void *, uint);

class Token
{
    void test()
   {
    memcmp (..., ..., ...);
   }
}

Was this an intended change of symbol naming?

I do use extern(C) inside the class definition but I thought the method had to be static. all my extern(C) inside the class are static and still compile and link with 0.81 Ant
Mar 23 2004
next sibling parent C <dont respond.com> writes:
Same here.  Requires the static keyword for methods.

C

On Tue, 23 Mar 2004 17:57:10 +0000 (UTC), Ant <Ant_member pathlink.com> 
wrote:

 In article <c3ptjf$1tg5$1 digitaldaemon.com>, Kris says...
 Pre v0.81 this would link correctly:

 class Token
 {
    extern (C) int memcmp (void *, void *, uint);

    void test()
   {
    memcmp (..., ..., ...);
   }
 }

 with v0.81, the linker fails with:

 Error 42: Symbol Undefined __D5hello5Token6memcmpUPvPvkZi

 If I move the extern (C) declaration outside of the class definition 
 (up to
 the global scope) it links correctly:

 extern (C) int memcmp (void *, void *, uint);

 class Token
 {
    void test()
   {
    memcmp (..., ..., ...);
   }
 }

 Was this an intended change of symbol naming?

I do use extern(C) inside the class definition but I thought the method had to be static. all my extern(C) inside the class are static and still compile and link with 0.81 Ant

-- D Newsgroup.
Mar 23 2004
prev sibling parent Carlos Santander B. <Carlos_member pathlink.com> writes:
In article <c3ptpm$1tto$1 digitaldaemon.com>, Ant says...
In article <c3ptjf$1tg5$1 digitaldaemon.com>, Kris says...
Pre v0.81 this would link correctly:

class Token
{
    extern (C) int memcmp (void *, void *, uint);

    void test()
   {
    memcmp (..., ..., ...);
   }
}

with v0.81, the linker fails with:

Error 42: Symbol Undefined __D5hello5Token6memcmpUPvPvkZi

If I move the extern (C) declaration outside of the class definition (up to
the global scope) it links correctly:

extern (C) int memcmp (void *, void *, uint);

class Token
{
    void test()
   {
    memcmp (..., ..., ...);
   }
}

Was this an intended change of symbol naming?

I do use extern(C) inside the class definition but I thought the method had to be static. all my extern(C) inside the class are static and still compile and link with 0.81 Ant

That was the first thing I tried, but that didn't work either. ------------------- Carlos Santander B.
Mar 23 2004
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
That actually was a bug fixed in the compiler. The memcmp() declaration is
declared as a virtual member function of Token with the C calling
convention. It really should be moved outside of the class, or declared as
static.

"Kris" <someidiot earthlink.net> wrote in message
news:c3ptjf$1tg5$1 digitaldaemon.com...
 Pre v0.81 this would link correctly:

 class Token
 {
     extern (C) int memcmp (void *, void *, uint);

     void test()
    {
     memcmp (..., ..., ...);
    }
 }

 with v0.81, the linker fails with:

 Error 42: Symbol Undefined __D5hello5Token6memcmpUPvPvkZi

 If I move the extern (C) declaration outside of the class definition (up

 the global scope) it links correctly:

 extern (C) int memcmp (void *, void *, uint);

 class Token
 {
     void test()
    {
     memcmp (..., ..., ...);
    }
 }

 Was this an intended change of symbol naming?

Mar 23 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:
 That actually was a bug fixed in the compiler. The memcmp() declaration is
 declared as a virtual member function of Token with the C calling
 convention. It really should be moved outside of the class, or declared as
 static.

Wouldn't a static method still be name-mangled? If it is then linking to memcmp still won't work, right? And if it isn't mangled then I think this is another bug. Otherwise you wouldn't be able to have static functions with the same name in different classes! Hauke
Mar 23 2004
next sibling parent reply Carlos Santander B. <Carlos_member pathlink.com> writes:
In article <c3q0qd$233o$1 digitaldaemon.com>, Hauke Duden says...
Walter wrote:
 That actually was a bug fixed in the compiler. The memcmp() declaration is
 declared as a virtual member function of Token with the C calling
 convention. It really should be moved outside of the class, or declared as
 static.

Wouldn't a static method still be name-mangled? If it is then linking to memcmp still won't work, right? And if it isn't mangled then I think this is another bug. Otherwise you wouldn't be able to have static functions with the same name in different classes! Hauke

Actually, that's what I was saying in my other post. Indeed, the linker complains and reports a name-mangled function. ------------------- Carlos Santander B.
Mar 23 2004
parent reply "Kris" <someidiot earthlink.net> writes:
As Carlos says: even if it's static within the class it will still be
name-mangled. The only solution is apparently to move such declarations up
to module-scope.

- Kris

"Carlos Santander B." <Carlos_member pathlink.com> wrote in message
news:c3q12m$23eb$1 digitaldaemon.com...
 In article <c3q0qd$233o$1 digitaldaemon.com>, Hauke Duden says...
Walter wrote:
 That actually was a bug fixed in the compiler. The memcmp() declaration



 declared as a virtual member function of Token with the C calling
 convention. It really should be moved outside of the class, or declared



 static.

Wouldn't a static method still be name-mangled? If it is then linking to memcmp still won't work, right? And if it isn't mangled then I think this is another bug. Otherwise you wouldn't be able to have static functions with the same name in different classes! Hauke

Actually, that's what I was saying in my other post. Indeed, the linker complains and reports a name-mangled function. ------------------- Carlos Santander B.

Mar 23 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Kris schrieb:

 As Carlos says: even if it's static within the class it will still be
 name-mangled. The only solution is apparently to move such declarations up
 to module-scope.
 
 - Kris

All declarations are name mangled in D, because they are mangled with module name and arguments. Exceptions are all declarations with extern(C/Pascal/Windows/...) sorts where name mangling is to be turned off. Always, not depending on whether it's a static member or module scope level. Obviously, making non-static members or inner functions extern is unfeasible. -eye
Mar 23 2004
parent reply "Kris" <someidiot earthlink.net> writes:
Yes Ilya, but the case in question *has* an extern (C) attribute ... to wit:

        extern (C) int memcmp (void *, void *, uint);

- Kris

"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:c3q886$2gk2$1 digitaldaemon.com...
 Kris schrieb:

 As Carlos says: even if it's static within the class it will still be
 name-mangled. The only solution is apparently to move such declarations


 to module-scope.

 - Kris

All declarations are name mangled in D, because they are mangled with module name and arguments. Exceptions are all declarations with extern(C/Pascal/Windows/...) sorts where name mangling is to be turned off. Always, not depending on whether it's a static member or module scope level. Obviously, making non-static members or inner functions extern is unfeasible. -eye

Mar 23 2004
parent reply "Derek Parnell" <Derek.Parnell psyc.ward> writes:
On Tue, 23 Mar 2004 16:34:51 -0800 (24/Mar/04 11:34:51 AM)
, Kris <someidiot earthlink.net> wrote:

 Yes Ilya, but the case in question *has* an extern (C) attribute ... to  
 wit:

         extern (C) int memcmp (void *, void *, uint);

 - Kris

 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 news:c3q886$2gk2$1 digitaldaemon.com...
 Kris schrieb:

 As Carlos says: even if it's static within the class it will still be
 name-mangled. The only solution is apparently to move such  


 to module-scope.

 - Kris

All declarations are name mangled in D, because they are mangled with module name and arguments. Exceptions are all declarations with extern(C/Pascal/Windows/...) sorts where name mangling is to be turned off. Always, not depending on whether it's a static member or module scope level. Obviously, making non-static members or inner functions extern is unfeasible.


Doesn't the 'extern (C)' qualification just tell DMD to avoid name-mangling for this function identifer? I can't see what you are trying to achieve by placing the memcmp reference inside a class definition. To me, it seems natural to place such 'extern (C)' references outside all any class. -- Derek
Mar 23 2004
parent "Kris" <someidiot earthlink.net> writes:
Derek: It was just a small convenience to place the declaration along with
the version() stuff (windows vs linux) within a class along with version
specific import's and so on. I usually like to keep related things together.

But the issue is really one of clarity: it's pretty clear that the extern()
mangling behavior was somewhat misunderstood, and not documented anywhere.

- Kris


"Derek Parnell" <Derek.Parnell psyc.ward> wrote in message
news:opr5cb75e3u2m3b2 news.digitalmars.com...
 On Tue, 23 Mar 2004 16:34:51 -0800 (24/Mar/04 11:34:51 AM)
 , Kris <someidiot earthlink.net> wrote:

 Yes Ilya, but the case in question *has* an extern (C) attribute ... to
 wit:

         extern (C) int memcmp (void *, void *, uint);

 - Kris

 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 news:c3q886$2gk2$1 digitaldaemon.com...
 Kris schrieb:

 As Carlos says: even if it's static within the class it will still be
 name-mangled. The only solution is apparently to move such


 to module-scope.

 - Kris

All declarations are name mangled in D, because they are mangled with module name and arguments. Exceptions are all declarations with extern(C/Pascal/Windows/...) sorts where name mangling is to be turned off. Always, not depending on whether it's a static member or module scope level. Obviously, making non-static members or inner functions extern is unfeasible.


Doesn't the 'extern (C)' qualification just tell DMD to avoid name-mangling for this function identifer? I can't see what you are trying to achieve by placing the memcmp reference inside a class definition. To me, it seems natural to place such 'extern (C)' references outside all any class. -- Derek

Mar 23 2004
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:c3q0qd$233o$1 digitaldaemon.com...
 Walter wrote:
 That actually was a bug fixed in the compiler. The memcmp() declaration


 declared as a virtual member function of Token with the C calling
 convention. It really should be moved outside of the class, or declared


 static.

Wouldn't a static method still be name-mangled?

It shouldn't be.
 If it is then linking to
 memcmp still won't work, right?

I'll check into it.
 And if it isn't mangled then I think this is another bug. Otherwise you
 wouldn't be able to have static functions with the same name in
 different classes!

That doesn't work in C++, either <g>. You can only have one function with a particular name and C linkage in the entire program.
Mar 23 2004
prev sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
Off Topic - I can't seem to have Thunderbird mark this thread as "read" 
- anyone else having the same issue or am I losing my marbles?

Kris wrote:
 Pre v0.81 this would link correctly:
 
 class Token
 {
     extern (C) int memcmp (void *, void *, uint);
 
     void test()
    {
     memcmp (..., ..., ...);
    }
 }
 
 with v0.81, the linker fails with:
 
 Error 42: Symbol Undefined __D5hello5Token6memcmpUPvPvkZi
 
 If I move the extern (C) declaration outside of the class definition (up to
 the global scope) it links correctly:
 
 extern (C) int memcmp (void *, void *, uint);
 
 class Token
 {
     void test()
    {
     memcmp (..., ..., ...);
    }
 }
 
 Was this an intended change of symbol naming?
 
 

Mar 26 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
I would think that this takes time in a newsgroup like this, and you may 
want to leave it alone for 20 seconds or so while it is showing you a 
sandclock.

Or what do you mean?

-eye

Brad Anderson schrieb:

 Off Topic - I can't seem to have Thunderbird mark this thread as "read" 
 - anyone else having the same issue or am I losing my marbles?

Mar 26 2004
parent reply Brad Anderson <brad sankaty.dot.com> writes:
This issue is since yesterday.  When I collapse the thread, it still has 
an underline, meaning there's at least one unread message in the thread. 
  When I expand it, all are read.  It's almost like someone posted a 
message and cancelled it before I read it.  Who knows.  It's not that 
big of a deal.

BA

Ilya Minkov wrote:
 I would think that this takes time in a newsgroup like this, and you may 
 want to leave it alone for 20 seconds or so while it is showing you a 
 sandclock.
 
 Or what do you mean?
 
 -eye
 
 Brad Anderson schrieb:
 
 Off Topic - I can't seem to have Thunderbird mark this thread as 
 "read" - anyone else having the same issue or am I losing my marbles?


Mar 26 2004
next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
Brad Anderson wrote:

 This issue is since yesterday.  When I collapse the thread, it still 
 has an underline, meaning there's at least one unread message in the 
 thread.  When I expand it, all are read.  It's almost like someone 
 posted a message and cancelled it before I read it.  Who knows.  It's 
 not that big of a deal.

 BA

I get this problem as well. I just ignore it. Or you can read everything and then reset everything, and mark everything as read. But that still doesn't work sometimes. -- -Anderson: http://badmama.com.au/~anderson/
Mar 27 2004
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
I think there was some sort of reordering yesterday or so, messages 
began disappearing one by one. Then i had clicked out of the newsgroup 
and back in and it restored all. I'm using the big Mozilla 1.6.

-eye

Brad Anderson schrieb:

 This issue is since yesterday.  When I collapse the thread, it still has 
 an underline, meaning there's at least one unread message in the thread. 
  When I expand it, all are read.  It's almost like someone posted a 
 message and cancelled it before I read it.  Who knows.  It's not that 
 big of a deal.
 
 BA

Mar 27 2004