[Issue 7024] inconsistent mangling of shared in extern(C++)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7024

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P2  |P3

--

[Issue 7024] inconsistent mangling of shared in extern(C++)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7024

Walter Bright  changed:

   What|Removed |Added

   Keywords||mangling
 CC||bugzi...@digitalmars.com

--

[Issue 7024] inconsistent mangling of shared in extern(C++)

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7024



--- Comment #8 from deadalnix deadal...@gmail.com 2011-12-03 04:42:25 PST ---
(In reply to comment #7)
 The baseline of D type system is to disallow things that can't be guaranteed.
 C++ definitely can't guarantee any of the three.
 To avoid explicit casting at every caller place, you could add
 a D wrapper that does the calling.
 
 extern(C++) void _spawn(void function() fun, void* data);
 
 void spawn(extern(C++) void function() fun, shared void* data)
 {
   _spawn(fun, cast(void*)data);
 }

This piece of code miss completely the point of the one before.

But back to the problem, obviously, C++ cannot guarantee, with it's type
system, that something is immutable, shared, or whatever. This is why a bindong
is required, and the same thing must be express the D way and the C++ way to
interact.

It is up to the person writting the binding to ensure that it is correct. C++
can have immutable data, or shared one's. It isn't guaranteed by the type
system, but can be guaranteed by the logic of the application. So it make sense
to express those in bindings.

C++ cannot guarantee anything that D guarantee. It can corrupt memory, share
non shared data across thread, etc . . . So if we agree on this argument,
extern(C++) must be simply and completely removed from D's specification and
implementation.

When it comes to binding, it is up to the person writting the binding to ensure
that code on both sides express the same thing, and it cannot, and never will,
be enforced by a specification.

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

[Issue 7024] inconsistent mangling of shared in extern(C++)

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7024



--- Comment #9 from d...@dawgfoto.de 2011-12-03 06:44:56 PST ---
- The current D policy is to not base such things on trust but
   require explicit casting.

 - You have no way to guarantee atomic access for shared in C++.

 - Overloaded extern(C++) functions will clash during linking or
   even worse resolve to the same symbol.

The only pro argument is less typing for the caller,
where the example code just showed another solution to this.

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

[Issue 7024] inconsistent mangling of shared in extern(C++)

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7024



--- Comment #6 from deadalnix deadal...@gmail.com 2011-12-02 10:59:31 PST ---
(In reply to comment #4)
 Rather than trying to fix the C++ mangling, wouldn't it make more sense to
 disallow 'shared' in extern(C++) declarations?

As thoses concept doesn't exists in C++, this is up to the C++ programmer to
ensure that something is shared or not. Sometime, C++ code is just made to
handle shared data, it is just not explicit.

In this case, you ends up using convoluted casts to handle everything.

I have a practical case : start a thread from C++, but that could interract
with D (so you must go throw D's way of starting thread). You end up writing
something like this :
alias extern(C++) void* function(void*) EntryPoint;
extern(C++) void* D_start_thread(EntryPoint entryPoint, void* userData) {
Tid tid = spawn(function void(EntryPoint entryPoint, shared void* userData)
{
entryPoint(cast(void*) userData);
}, entryPoint, cast(shared void*) userData);

return cast(void*) [tid].ptr;
}

So I would recommand to ignore shared in mangling of C++ function and mangle
immutable as const. It is up to the programmer to ensure that thoses are right
qualifiers.

inout can't be handled nicely so it should generate a compile time error.

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

[Issue 7024] inconsistent mangling of shared in extern(C++)

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7024



--- Comment #7 from d...@dawgfoto.de 2011-12-02 12:22:18 PST ---
The baseline of D type system is to disallow things that can't be guaranteed.
C++ definitely can't guarantee any of the three.
To avoid explicit casting at every caller place, you could add
a D wrapper that does the calling.

extern(C++) void _spawn(void function() fun, void* data);

void spawn(extern(C++) void function() fun, shared void* data)
{
  _spawn(fun, cast(void*)data);
}

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

[Issue 7024] inconsistent mangling of shared in extern(C++)

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7024


Iain Buclaw ibuc...@ubuntu.com changed:

   What|Removed |Added

 CC||ibuc...@ubuntu.com


--- Comment #4 from Iain Buclaw ibuc...@ubuntu.com 2011-12-01 09:46:53 PST ---
Rather than trying to fix the C++ mangling, wouldn't it make more sense to
disallow 'shared' in extern(C++) declarations?

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

[Issue 7024] inconsistent mangling of shared in extern(C++)

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7024



--- Comment #5 from d...@dawgfoto.de 2011-12-01 12:50:37 PST ---
It'd be a cleaner cut to disallow immutable/shared/inout for extern(C++)
declarations. Not sure though how big the impact is.

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

[Issue 7024] inconsistent mangling of shared in extern(C++)

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7024



--- Comment #3 from d...@dawgfoto.de 2011-11-29 10:05:37 PST ---
current workaround:

Don't use shared/immutable/inout with extern(C++) declarations.

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

[Issue 7024] inconsistent mangling of shared in extern(C++)

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7024


deadalnix deadal...@gmail.com changed:

   What|Removed |Added

 CC||deadal...@gmail.com


--- Comment #1 from deadalnix deadal...@gmail.com 2011-11-28 03:26:40 PST ---
Hi,

As I said in the topic, I was using GDC to generate informations. I didn't try
with DMD so it is not sure the problem actually exists on this compiler.

I'm currently repporting the issue to GDC bugtracker.

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

[Issue 7024] inconsistent mangling of shared in extern(C++)

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7024



--- Comment #2 from d...@dawgfoto.de 2011-11-28 05:15:24 PST ---
Yes, it exists with dmd too.

It is an error with the compression in name mangling.
http://sourcery.mentor.com/public/cxx-abi/abi.html#mangling-compression
The compiler fails to substitute 'void*' and 'shared void*'.
But for both shared is ignored for mangling.

It needs to be decided whether all qualifiers (probably except for const)
be silently stripped or if they should result in an error/warning.

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