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

"Kris" <someidiot earthlink.net> Mar 23 2004

Ant <Ant_member pathlink.com> Mar 23 2004

C <dont respond.com> Mar 23 2004
Carlos Santander B. <Carlos_member pathlink.com> Mar 23 2004

"Walter" <walter digitalmars.com> Mar 23 2004

Hauke Duden <H.NS.Duden gmx.net> Mar 23 2004

Carlos Santander B. <Carlos_member pathlink.com> Mar 23 2004

"Kris" <someidiot earthlink.net> Mar 23 2004

Ilya Minkov <minkov cs.tum.edu> Mar 23 2004

"Kris" <someidiot earthlink.net> Mar 23 2004

"Derek Parnell" <Derek.Parnell psyc.ward> Mar 23 2004

"Kris" <someidiot earthlink.net> Mar 23 2004

"Walter" <walter digitalmars.com> Mar 23 2004

Brad Anderson <brad sankaty.dot.com> Mar 26 2004

Ilya Minkov <minkov cs.tum.edu> Mar 26 2004

Brad Anderson <brad sankaty.dot.com> Mar 26 2004

J Anderson <REMOVEanderson badmama.com.au> Mar 27 2004
Ilya Minkov <minkov cs.tum.edu> Mar 27 2004

"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

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

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

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

"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

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

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

"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

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

"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

"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

"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

"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

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

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

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

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

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

D Programming

C/C++ Programming

Other

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