D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 6132 - extern (C) Silently Ignored Within D Classes
Summary: extern (C) Silently Ignored Within D Classes
Status: NEW
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: x86 Mac OS X
: P3 normal
Assignee: No Owner
URL:
Keywords: bootcamp
: 7005 (view as issue list)
Depends on:
Blocks:
 
Reported: 2011-06-09 09:17 UTC by Braxton Sherouse
Modified: 2024-12-13 17:55 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Braxton Sherouse 2011-06-09 09:17:03 UTC 
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
Comment 1 Braxton Sherouse 2011-06-25 19:41:29 UTC 
Another peculiarity to add:

class Sprocket {
    extern (C) static int clock(); // not added to the symbol table!
}
Comment 2 Martin Nowak 2011-11-26 08:54:58 UTC 
The latter happens when you don't reference that function.
Comment 3 Martin Nowak 2011-11-26 11:40:56 UTC 
*** Issue 7005 has been marked as a duplicate of this issue. ***
Comment 4 Martin Nowak 2011-11-29 08:59:07 UTC 
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.
Comment 5 Andrei Alexandrescu 2016-10-14 16:54:36 UTC 
@Martin so is there anything to fix for this?
Comment 6 anonymous4 2016-10-18 08:29:32 UTC 
(In reply to Martin Nowak from comment #4)
> A clean cut would be to disallow extern(C/Pascal/Windows) on structure level
> except for static methods.

extern(Windows) methods are needed for COM.
Comment 7 dlangBugzillaToGithub 2024-12-13 17:55:28 UTC 
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dmd/issues/18346

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB