www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6132] New: extern (C) Silently Ignored Within D Classes

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6132

           Summary: extern (C) Silently Ignored Within D Classes
           Product: D
           Version: D2
          Platform: x86
        OS/Version: Mac OS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: sherouse email.virginia.edu



09:17:03 PDT ---
Overview:

I'm running DMD32 v2.053 on Mac OS X 10.6.7 and found the following
inconsistency in name mangling:

====
extern(C) int clock(); // is mangled to _clock

class Sprocket {
  extern(C) int clock(); // is mangled to __D4test8Sprocket5clockMUZi:
}
====

Expected Results:

The compiler should either:
1) mangle the declaration according to the C conventions by cause of the
"extern (C)", or:
2) emit a compilation error because C doesn't have classes.

Actual Results:

The declaration is silently compiled according to the D conventions.

Additional Information:

While either solution would be welcomed, I'm working in context where solution
1 would save a lot of effort; I'm generating language/library bindings at
compile time through the use of template metaprogramming. The code builds a
(more robust) interface in D, and is just using the extern (C) to declare C
functions that will later be linked in from other libraries.

Maybe it would be possible for the compiler to allow this syntax when there is
no function body, but fail when there is??


Many thanks!
-braxton

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 09 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6132




19:41:29 PDT ---
Another peculiarity to add:

class Sprocket {
    extern (C) static int clock(); // not added to the symbol table!
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 25 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6132


dawg dawgfoto.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dawg dawgfoto.de



The latter happens when you don't reference that function.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 26 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6132




*** Issue 7005 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 26 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6132




Actually one needs to note, that extern(C) is not ignored for the calling
convention. It is only ignored for the mangling and the hidden this argument.
It even results in different delegate types for extern(C) and extern(D)
methods.

So on a struct method extern(C) behaves as __cdecl but not as extern(C).

A clean cut would be to disallow extern(C/Pascal/Windows) on structure level
except for static methods.

If there were a real need for declaring the calling convention than that should
become a different construct.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 29 2011