www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why are extern(C/C++) definitions and references mangled differently

reply Max Samukha <maxsamukha gmail.com> writes:
Consider the following two modules:

1. test.d:

module test;

import lib.a;

void main() {
     foo();
}


2. lib/a.d:

module lib.a;

extern(C) void foo() {}


When compiled separately (dmd -c lib/a.d; dmd test.d a.o), the 
function in 'a.o' is mangled as 'foo', but the reference in 
'test.o' is mangled as '_D3lib1a3fooFZv', which leads to a link 
error. I would expect both of them to be either plain C mangling, 
or fully qualified D (better). What is the reason for current 
behavior?
Sep 06 2019
next sibling parent reply 0xEAB <desisma heidel.beer> writes:
On Friday, 6 September 2019 at 15:09:22 UTC, Max Samukha wrote:

 Consider the following two modules:


What compiler version are you using?
Sep 06 2019
parent Max Samukha <maxsamukha gmail.com> writes:
On Friday, 6 September 2019 at 15:32:07 UTC, 0xEAB wrote:

 On Friday, 6 September 2019 at 15:09:22 UTC, Max Samukha wrote:

 Consider the following two modules:


 What compiler version are you using?


DMD64 D Compiler v2.088.0-1-g4011382ea, linux
Sep 06 2019
prev sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 6 September 2019 at 15:09:22 UTC, Max Samukha wrote:

 Consider the following two modules:

 1. test.d:

 module test;

 import lib.a;

 void main() {
     foo();
 }


 2. lib/a.d:

 module lib.a;

 extern(C) void foo() {}


 When compiled separately (dmd -c lib/a.d; dmd test.d a.o), the 
 function in 'a.o' is mangled as 'foo', but the reference in 
 'test.o' is mangled as '_D3lib1a3fooFZv', which leads to a link 
 error. I would expect both of them to be either plain C 
 mangling, or fully qualified D (better). What is the reason for 
 current behavior?


If that is happening you hit a bug.
It seems unlikely though.
Sep 06 2019
parent reply Max Samukha <maxsamukha gmail.com> writes:
On Friday, 6 September 2019 at 15:52:46 UTC, Stefan Koch wrote:

 On Friday, 6 September 2019 at 15:09:22 UTC, Max Samukha wrote:

 Consider the following two modules:

 1. test.d:

 module test;

 import lib.a;

 void main() {
     foo();
 }


 2. lib/a.d:

 module lib.a;

 extern(C) void foo() {}


 When compiled separately (dmd -c lib/a.d; dmd test.d a.o), the 
 function in 'a.o' is mangled as 'foo', but the reference in 
 'test.o' is mangled as '_D3lib1a3fooFZv', which leads to a 
 link error. I would expect both of them to be either plain C 
 mangling, or fully qualified D (better). What is the reason 
 for current behavior?


 If that is happening you hit a bug.
 It seems unlikely though.


Could you elaborate a bit? How should extern(C/C++) definitions 
be mangled - fully qualified or not, and why is the reference to 
extern(C/C++) D-mangled? The spec seems to say nothing about it.
Sep 06 2019
parent reply Max Samukha <maxsamukha gmail.com> writes:
On Friday, 6 September 2019 at 16:55:31 UTC, Max Samukha wrote:

 On Friday, 6 September 2019 at 15:52:46 UTC, Stefan Koch wrote:



 If that is happening you hit a bug.
 It seems unlikely though.


 Could you elaborate a bit? How should extern(C/C++) definitions 
 be mangled - fully qualified or not, and why is the reference 
 to extern(C/C++) D-mangled? The spec seems to say nothing about 
 it.


Ok, I have figured it out. There was 'a.di' file along with 'a.d' 
in the same directory, with a definition of extern(D) foo. That 
file was silently imported by the compiler (probably, a bug). 
Thank you for your attention.
Sep 06 2019
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 6 September 2019 at 17:42:08 UTC, Max Samukha wrote:

 That file was silently imported by the compiler (probably, a 
 bug).


That's by design - the automatic module import lookups actually 
always look for .di file first, then .d files.
Sep 06 2019
parent reply Max Samukha <maxsamukha gmail.com> writes:
On Friday, 6 September 2019 at 17:54:51 UTC, Adam D. Ruppe wrote:

 On Friday, 6 September 2019 at 17:42:08 UTC, Max Samukha wrote:

 That file was silently imported by the compiler (probably, a 
 bug).


 That's by design - the automatic module import lookups actually 
 always look for .di file first, then .d files.


Is there any practical use of having identically named .d and .di 
alongside?
Sep 06 2019
parent reply Jacob Carlborg <doob me.com> writes:
On 2019-09-06 21:03, Max Samukha wrote:


 Is there any practical use of having identically named .d and .di 
 alongside?


Same as in C/C++. This allows you to have a header file if you want to 
distribute a closed source library.

-- 
/Jacob Carlborg
Sep 07 2019
parent Max Samukha <maxsamukha gmail.com> writes:
On Saturday, 7 September 2019 at 13:01:38 UTC, Jacob Carlborg 
wrote:

 On 2019-09-06 21:03, Max Samukha wrote:


 Is there any practical use of having identically named .d and 
 .di alongside?


 Same as in C/C++. This allows you to have a header file if you 
 want to distribute a closed source library.


I know, but I have never seen a D project that would generate 
headers into the source directory. C++ requires headers for 
sharing declarations with other translation units in the project, 
even if the headers are not intended for distribution. That is 
why having headers alongside implementations is a common case 
there. D doesn't require that.

Anyway, that's a minor concern. Thank you.
Sep 07 2019