www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - extern(C) names are being mangled; that's crazy, Walter says I'm crazy

reply Manu <turkeyman gmail.com> writes:
https://issues.dlang.org/show_bug.cgi?id=20012

I need to know who is the crazy one here?
I can't believe the idea that extern(C) functions being mangled to
un-knowable generated names is what any sane user would ever expect.

Surely extern(C) means extern(C)?

I'd like a poll here...
Jul 23
next sibling parent Newbie2019 <newbie2019 gmail.com> writes:
On Wednesday, 24 July 2019 at 05:03:16 UTC, Manu wrote:
 https://issues.dlang.org/show_bug.cgi?id=20012

 I need to know who is the crazy one here?
 I can't believe the idea that extern(C) functions being mangled 
 to
 un-knowable generated names is what any sane user would ever 
 expect.

 Surely extern(C) means extern(C)?

 I'd like a poll here...
I just has the same problem yesterday, I just fix it by move the extern(C) out from mixin template to workaround.
Jul 23
prev sibling next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Wednesday, 24 July 2019 at 05:03:16 UTC, Manu wrote:
 https://issues.dlang.org/show_bug.cgi?id=20012

 I need to know who is the crazy one here?
 I can't believe the idea that extern(C) functions being mangled 
 to
 un-knowable generated names is what any sane user would ever 
 expect.

 Surely extern(C) means extern(C)?

 I'd like a poll here...
Just for comparison, here's what Rust does: https://doc.rust-lang.org/std/keyword.extern.html I like the fact that `extern` and `mangle` mean different things, but I don't like the way D currently implements it. Here's how I would design it. 1. `pragma(mangle)` should come in more forms. a. `pragma(mangle, C)` will mangle according to C rules b. `pragma(mangle, C++)` will mangle according to C++ rules c. `pragma(mangle, D)` will mangle according to D rules d. `pragma(mangle, "foo")` will mangle explicitly 2. `extern` should default the mangling to one of the above a. `extern(C)` should mean `extern(C) pragma(mangle, C)` b. `extern(C++)` should mean `extern(C++) pragma(mangle, C++)` c. `extern(D)` should mean `extern(D) pragma(mangle, D)` So, this code... struct S { extern(C) void foo() { } } ... would actually translate into... struct S { extern(C) pragma(mangle, C) void foo() { } } ... which, IIUC, would ultimately mean... struct S { extern(C) pragma(mangle, "foo") void foo() { } } This code... mixin template M() { extern(C) void fun() {} } mixin M!(); ... would result in ... { extern(C) pragma(mangle, C) void fun() {} } ... which, in turn, would result in ... { extern(C) pragma(mangle, "fun") void fun() {} } If the user instantiates the mixin multiple times, they will get duplicate symbol errors from the linker. If they wanted to take control, they would have to opt into a different mangling scheme such as... mixin template M() { extern(C) pragma(mangle, D) void fun() {} } ... which I, IIUC, would result in the current behavior. If the compiler cannot deterministically compute the mangling scheme specified because there is no translation from the D code, the compiler would emit a meaningful error telling the user so, and they may be able to work around it with the explicit `pragma(mangle)` form. IMO, that would be the most practical, covering the most common cases, and would also be the least surprising. So, in general, I side with Manu here, but I expect a little more from the language. Mike
Jul 23
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Mike Franklin wrote:

    a. `extern(C)` should mean `extern(C) pragma(mangle, C)`
then your code samples cannot be compiled at all, because each `extern(C)` will in turn be expaned to`extern(C) pragma(mangle, C)`, and the loop will go on. also, i won't even try to explain to somebody that "`extern(C)` means `extern(C) blah-blah`, but you see, the second "extern" is special, because... ahem... just because."
Jul 24
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 24 July 2019 at 09:44:19 UTC, ketmar wrote:

Nice to see you here again, ketmar ...
Jul 24
parent ketmar <ketmar ketmar.no-ip.org> writes:
Paolo Invernizzi wrote:

 On Wednesday, 24 July 2019 at 09:44:19 UTC, ketmar wrote:

 Nice to see you here again, ketmar ...
thank you. i'm still lurking here, only don't have enough time for D these days. but this issue managed to trigger me somehow.
Jul 24
prev sibling parent sarn <sarn theartofmachinery.com> writes:
On Wednesday, 24 July 2019 at 06:25:50 UTC, Mike Franklin wrote:
 1. `pragma(mangle)` should come in more forms.
   a. `pragma(mangle, C)` will mangle according to C rules
   b. `pragma(mangle, C++)` will mangle according to C++ rules
   c. `pragma(mangle, D)` will mangle according to D rules
   d. `pragma(mangle, "foo")` will mangle explicitly

 2. `extern` should default the mangling to one of the above
   a. `extern(C)` should mean `extern(C) pragma(mangle, C)`
   b. `extern(C++)` should mean `extern(C++) pragma(mangle, C++)`
   c. `extern(D)` should mean `extern(D) pragma(mangle, D)`
Yeah. Walter's approach is the only one that works well without a pragma(mangle, D), but I think pragma(mangle, D) is a better idea.
Jul 24
prev sibling next sibling parent aliak <something something.com> writes:
On Wednesday, 24 July 2019 at 05:03:16 UTC, Manu wrote:
 https://issues.dlang.org/show_bug.cgi?id=20012

 I need to know who is the crazy one here?
 I can't believe the idea that extern(C) functions being mangled 
 to
 un-knowable generated names is what any sane user would ever 
 expect.

 Surely extern(C) means extern(C)?

 I'd like a poll here...
I'm not sure. If there's an extern(C) in a mixin template, the prime purpose of which is to be reusable, does it make sense to instantiate that multiple times? Won't there then be multiple C-compatible symbols of the same thing, but with different semantics based on the context of the mixin template?
Jul 24
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
I never called you crazy, or anything remotely like that.
Jul 24
parent reply Manu <turkeyman gmail.com> writes:
On Wed., 24 Jul. 2019, 2:20 am Walter Bright via Digitalmars-d, <
digitalmars-d puremagic.com> wrote:

 I never called you crazy, or anything remotely like that.
Just kill me and bring me peace. I lose my mind trying to argue with you, and get so frustrated and angry, I just have to take a week or 2 timeout. I feel like this community just grinds my life away slowly but steadily and I hate participating, but I'm in too deep. I just want to kick my goal and get on with my job! Everything is just so hard, and so very weird. Why can't stuff just be predictable? Why does everything have to have weird special case rules and strange edge cases? My biggest trouble with D recently had been trying to explain it to people, and make them not lose confidence when they run in to a long series of stuff like this. I have to try and explain weird shit like it's got a good reason with a straight face, and I just can't do that on so many accounts! This is D's biggest enemy in 2019, I'm sure of it. Anyway... I'm sorry, this is actually a distraction. I've managed to lose my laser focus on shared stuff. That's what I need today to progress.

Jul 24
next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
On Wednesday, 24 July 2019 at 09:56:50 UTC, Manu wrote:
 On Wed., 24 Jul. 2019, 2:20 am Walter Bright via Digitalmars-d, 
 < digitalmars-d puremagic.com> wrote:

 I never called you crazy, or anything remotely like that.
Just kill me and bring me peace. I lose my mind trying to argue with you, and get so frustrated and angry, I just have to take a week or 2 timeout. I feel like this community just grinds my life away slowly but steadily and I hate participating, but I'm in too deep. I just want to kick my goal and get on with my job! Everything is just so hard, and so very weird. Why can't stuff just be predictable? Why does everything have to have weird special case rules and strange edge cases? My biggest trouble with D recently had been trying to explain it to people, and make them not lose confidence when they run in to a long series of stuff like this. I have to try and explain weird shit like it's got a good reason with a straight face, and I just can't do that on so many accounts! This is D's biggest enemy in 2019, I'm sure of it.
I definitely agree that D as a language has taken on way way too much complexity, and is taking on more complexity all the time, it's not sustainable and we *need* to get on top of it, somehow, though I have no idea what can be done. That said, imo you should *definitely* take a break on this; you sound like you're one negative feedback away from burnout.
Jul 24
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/24/2019 2:56 AM, Manu wrote:
 Just kill me and bring me peace.
 I lose my mind trying to argue with you, and get so frustrated and angry, I
just 
 have to take a week or 2 timeout.
On the other hand, you've gotten: 1. user defined attributes 2. rvalue reference parameters 3. restricted shared access 4. mixin types 5. the namespace string thing
Jul 24
next sibling parent SashaGreat <s g.com> writes:
On Wednesday, 24 July 2019 at 23:03:59 UTC, Walter Bright wrote:
 On 7/24/2019 2:56 AM, Manu wrote:
 Just kill me and bring me peace.
 I lose my mind trying to argue with you, and get so frustrated 
 and angry, I just have to take a week or 2 timeout.
On the other hand, you've gotten: 1. user defined attributes 2. rvalue reference parameters 3. restricted shared access 4. mixin types 5. the namespace string thing
Touché!
Jul 24
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On Wed., 24 Jul. 2019, 4:05 pm Walter Bright via Digitalmars-d, <
digitalmars-d puremagic.com> wrote:

 On 7/24/2019 2:56 AM, Manu wrote:
 Just kill me and bring me peace.
 I lose my mind trying to argue with you, and get so frustrated and
angry, I just
 have to take a week or 2 timeout.
On the other hand, you've gotten: 1. user defined attributes 2. rvalue reference parameters 3. restricted shared access 4. mixin types 5. the namespace string thing
Don't forget extern(C++), nogc, win64... ;)

More than 10 years and a crazy amount of time arguing for some of those
though!

But this isn't like that... This isn't in the major or controversial
feature category, it's just a bug... but apparently it's not; it's by
design, and the design is great.


Jul 24
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/24/2019 4:03 PM, Walter Bright wrote:
 On the other hand, you've gotten:
 
 1. user defined attributes
 2. rvalue reference parameters
 3. restricted shared access
 4. mixin types
 5. the namespace string thing
6. Windows 64 code generator
Jul 24
parent reply Elvis Zhou <elvis.x.zhou gmail.com> writes:
On Thursday, 25 July 2019 at 03:56:57 UTC, Walter Bright wrote:
 On 7/24/2019 4:03 PM, Walter Bright wrote:
 On the other hand, you've gotten:
 
 1. user defined attributes
 2. rvalue reference parameters
 3. restricted shared access
 4. mixin types
 5. the namespace string thing
6. Windows 64 code generator
these won't make people come, one weird shit make people go
Jul 24
parent reply Walter Bright <newshound2 digitalmars.com> writes:
We expect professional demeanor here, not cussing.
Jul 25
parent Elvis Zhou <elvis.x.zhou gmail.com> writes:
On Thursday, 25 July 2019 at 07:06:28 UTC, Walter Bright wrote:
 We expect professional demeanor here, not cussing.
No offence here, my point was that, we should first focus on fixing those weird things, other than expanding the language with new features, since it's obvious once a user quit with bad impressions after coming and trying d, he'll never back and we lose him forever, the inconsistency Manu mentioned is determined to give a bad impression.
Jul 25
prev sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 24 July 2019 at 09:56:50 UTC, Manu wrote:
 On Wed., 24 Jul. 2019, 2:20 am Walter Bright via Digitalmars-d, 
 < digitalmars-d puremagic.com> wrote:

 I never called you crazy, or anything remotely like that.
Just kill me and bring me peace. I lose my mind trying to argue with you, and get so frustrated and angry, I just have to take a week or 2 timeout. I feel like this community just grinds my life away slowly but steadily and I hate participating, but I'm in too deep. I just want to kick my goal and get on with my job! Everything is just so hard, and so very weird. Why can't stuff just be predictable? Why does everything have to have weird special case rules and strange edge cases? My biggest trouble with D recently had been trying to explain it to people, and make them not lose confidence when they run in to a long series of stuff like this. I have to try and explain weird shit like it's got a good reason with a straight face, and I just can't do that on so many accounts! This is D's biggest enemy in 2019, I'm sure of it. Anyway... I'm sorry, this is actually a distraction. I've managed to lose my laser focus on shared stuff. That's what I need today to progress.
You're not crazy. Walter can bey hard to discuss things with. I think he's tired of discussing things after so many years. He tends to ignore most things and only responds to what he thinks is important. If you're feeling burnt out, imagine how he feels after all the years he's been doing this. But know that you're not the only one who feels this way, and Walter tends to have a very different viewpoint on things. So don't take it personally, just because he disagrees with you doesn't mean you're wrong. As for this subject, I expect extern (C) to change both the API and the mangling, so I would expect the behavior described by Manu. However, I can see use cases for only changing the ABI while keeping mangling. It is very weird that extern (C) affects both in normal code, and only the ABI when it's inside a mixin template. Sounds like one of those very odd cases in C++ that Scott Meyers would put on one of his slides :) Dconf 2014 Day 2 Keynote: The Last Thing D Needs -- Scott Meyers https://www.youtube.com/watch?v=KAWA1DuvCnQ After reading the thread and thinking on a bit, it seems like it would be simpler to have extern (C) do the same thing in all cases, which would be to change the ABI and the mangling. If you want D mangling, use mangle(D) or something along with extern (C).
Jul 24
parent Aliak <something something.com> writes:
On Thursday, 25 July 2019 at 00:24:11 UTC, Jonathan Marler wrote:
 On Wednesday, 24 July 2019 at 09:56:50 UTC, Manu wrote:
 [...]
You're not crazy. Walter can bey hard to discuss things with. I think he's tired of discussing things after so many years. He tends to ignore most things and only responds to what he thinks is important. If you're feeling burnt out, imagine how he feels after all the years he's been doing this. But know that you're not the only one who feels this way, and Walter tends to have a very different viewpoint on things. So don't take it personally, just because he disagrees with you doesn't mean you're wrong. As for this subject, I expect extern (C) to change both the API and the mangling, so I would expect the behavior described by Manu. However, I can see use cases for only changing the ABI while keeping mangling. It is very weird that extern (C) affects both in normal code, and only the ABI when it's inside a mixin template. Sounds like one of those very odd cases in C++ that Scott Meyers would put on one of his slides :) Dconf 2014 Day 2 Keynote: The Last Thing D Needs -- Scott Meyers https://www.youtube.com/watch?v=KAWA1DuvCnQ After reading the thread and thinking on a bit, it seems like it would be simpler to have extern (C) do the same thing in all cases, which would be to change the ABI and the mangling. If you want D mangling, use mangle(D) or something along with extern (C).
Ok, I think after reading this and the bug report, and the mentioned uses cases, the callback case is the one that should be treated differently, and not the vanilla case. So mangle(D) and extern(C) if you want mangling to be different for a C function makes things consistent and expected.
Jul 25
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 24 July 2019 at 05:03:16 UTC, Manu wrote:
 I can't believe the idea that extern(C) functions being mangled 
 to un-knowable generated names is what any sane user would ever 
 expect.
I have used this pattern for callbacks before without even thinking about it, and it just worked. I have also hit some annoyance like you saw (and before pragma(mangle) it was really annoying, now it is just "huh i forgot to do that"). I wonder if you have ever done a callback use case too and never even noticed it exactly because it just works, but then pay a lot of attention to this because it doesn't.
Jul 24
parent reply Manu <turkeyman gmail.com> writes:
On Wed, Jul 24, 2019 at 6:55 AM Adam D. Ruppe via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Wednesday, 24 July 2019 at 05:03:16 UTC, Manu wrote:
 I can't believe the idea that extern(C) functions being mangled
 to un-knowable generated names is what any sane user would ever
 expect.
I have used this pattern for callbacks before without even thinking about it, and it just worked. I have also hit some annoyance like you saw (and before pragma(mangle) it was really annoying, now it is just "huh i forgot to do that").
In that callback case, they're effectively anonymously named functions... The name is irrelevant, and so is the mangling. So that is the case where pragma(mangle, "IDontCare") should be used. There shouldn't be edge cases and surprises where extern(C) means something sometimes, and something else in this weird edge case.
 I wonder if you have ever done a callback use case too and never
 even noticed it exactly because it just works, but then pay a lot
 of attention to this because it doesn't.
I have not. I would *never* expect to declare multiple extern(C) functions with the same name from the same file and not have link errors. Nobody would expect that. Mangling extern(C) functions is ABSOLUTELY NOT extern(C). If I didn't get the link error I was expecting, I would be angry, and emitting the exact same rant. extern(C) shouldn't mean different shit in different cases. I can't believe anyone thinks that's okay.
Jul 24
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/24/2019 2:24 PM, Manu wrote:
 In that callback case, they're effectively anonymously named
 functions...
Yet they are given a name, and extern(C) to get the right calling convention.
Jul 24
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Wednesday, 24 July 2019 at 23:05:33 UTC, Walter Bright wrote:
 On 7/24/2019 2:24 PM, Manu wrote:
 In that callback case, they're effectively anonymously named
 functions...
Yet they are given a name, and extern(C) to get the right calling convention.
I think the issue here is one of definitions and I think I understand why Walter and Manu do not understand each others point. For Manu extern(?) is mostly about mangling and secondarily about calling convention. For Walter, its first and foremost about calling convention. The mangling being unimportant as it can be explicitly set with mangle. When looking at what the specs says [1] it's clear that extern is more about calling conventions than mangling [1]: https://dlang.org/spec/attribute.html#linkage
Jul 26
next sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Friday, 26 July 2019 at 12:55:10 UTC, Patrick Schluter wrote:
 On Wednesday, 24 July 2019 at 23:05:33 UTC, Walter Bright wrote:
 On 7/24/2019 2:24 PM, Manu wrote:
 In that callback case, they're effectively anonymously named
 functions...
Yet they are given a name, and extern(C) to get the right calling convention.
I think the issue here is one of definitions and I think I understand why Walter and Manu do not understand each others point. For Manu extern(?) is mostly about mangling and secondarily about calling convention. For Walter, its first and foremost about calling convention. The mangling being unimportant as it can be explicitly set with mangle. When looking at what the specs says [1] it's clear that extern is more about calling conventions than mangling [1]: https://dlang.org/spec/attribute.html#linkage
To clarify. The issue here is that extern(?) is one keyword acting on 2 different things that are only loosely linked: the calling convention and the naming convention. What the different versions (C, C++, D, Windows, System, Objective-C) actually really do is very sketchy and not well defined and can even change from platform to platform (C++ mangles differently on Windows and Linux afaik).
Jul 26
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On Fri, Jul 26, 2019 at 6:00 AM Patrick Schluter via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Wednesday, 24 July 2019 at 23:05:33 UTC, Walter Bright wrote:
 On 7/24/2019 2:24 PM, Manu wrote:
 In that callback case, they're effectively anonymously named
 functions...
Yet they are given a name, and extern(C) to get the right calling convention.
I think the issue here is one of definitions and I think I understand why Walter and Manu do not understand each others point. For Manu extern(?) is mostly about mangling and secondarily about calling convention. For Walter, its first and foremost about calling convention. The mangling being unimportant as it can be explicitly set with mangle. When looking at what the specs says [1] it's clear that extern is more about calling conventions than mangling [1]: https://dlang.org/spec/attribute.html#linkage
I'm pretty sure it's about both... you can't separate them and still be the thing that's written on the tin. It's highly surprising, and I raise the issue as important having recently witnessed multiple people being surprised and unimpressed with this particular quirk. I've talked a lot about tidying up weird shit that makes bad impressions; I'm getting tired of too many little things adding up this way, and making it really hard for me to get colleagues invested and build confidence, this is one such thing.
Jul 26
parent reply Ethan <gooberman gmail.com> writes:
On Friday, 26 July 2019 at 21:34:29 UTC, Manu wrote:
 I'm pretty sure it's about both
100% this. D can't claim complete 100% C interoperability if it can't generate symbols that a C compiler expects to find. Here's the insane thing about all this, for all those playing at home. Take Manu's example, but add two little "++" symbols. ie: export extern(C++) void fun() {} AND mixin template M() { export extern(C++) void fun() {} } mixin M!(); You know what pragma( msg, fun.mangleof ) prints for both of them? The exact same symbol, of course. _Z3funv on Linux, ?fun YAXXZ on Windows. What actual legit "this is why this is bad in a production environment" reason is there to work as expected for C++ but not for C? -- Manu keeps bringing up getting colleagues using D. It's not difficult to find out who he works for. It's not difficult to imagine how good it would be for D if D would enter wide usage among his colleagues. Looking through the bug report. "You can get the behaviour you wanted with this code hack." No. This *cannot* be the face of the D language. Simple stuff like this should Just Work(TM).
Jul 26
parent reply Manu <turkeyman gmail.com> writes:
On Fri, Jul 26, 2019 at 8:10 PM Ethan via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Friday, 26 July 2019 at 21:34:29 UTC, Manu wrote:
 I'm pretty sure it's about both
100% this. D can't claim complete 100% C interoperability if it can't generate symbols that a C compiler expects to find.
It obviously can, it's just a really weird edge case. The reason is that it turns out mixin introduces a named scope; something that I think 99% of people have no idea about, and I'm not sure is helpful. If mixin doesn't mean mixin, but rather "mix nearby then alias", I don't find that intuitive. Every mixin I've ever written, I author it in such a way that if it were to be used multiple times in the same scope, I handle that if it's designed to work that way, or I produce an error. I bet everyone does this? I also expect that if I wanted to make colliding symbols in the same scope, I could do that too. I don't love that mixin creates a scope, it seems weird and pointless and possibly easy to accidentally hide stuff by mistake... If I wanted a scope, I'd put a scope in my mixin. I don't believe anyone would expect this. But in particular, the idea that mangling doesn't work because a function is in a mixin; that's just too surprising to accept.
 export extern(C++) void fun() {}

 AND

 mixin template M()
 {
    export extern(C++) void fun() {}
 }
 mixin M!();

 You know what pragma( msg, fun.mangleof ) prints for both of them?

 The exact same symbol, of course. _Z3funv on Linux, ?fun  YAXXZ
 on Windows.
Oh really? Serious? Yeah, this is just a plain straight-up bug. There's no excluse for this.
 Looking through the bug report. "You can get the behaviour you
 wanted with this code hack." No. This *cannot* be the face of the
 D language. Simple stuff like this should Just Work(TM).
Right, you don't move to a shiny new futuristic modern language so you can start writing weird work-arounds that I can't explain to people on day-one... it really does make a very bad impression.
Jul 26
parent burjui <bytefu gmail.com> writes:
So you feel frustrated, having spent so much time arguing with 
Walter and explaining D bugs and "features" to colleagues? Guess 
what, there is a simple solution to your problem, which worked 
wonderfully for me - stop using D.

I wrote a whole rant about D's lack of solid computer science 
foundation, poor management and 20 years of development, but 
decided to not keep it, because it will not affect D development 
anyway and will definitely offend some people. I'll put it this 
way: Andrei's involvement is the best thing that happened to D 
ever, but that is not enough.

Just stop using D and move on. It doesn't really matter if D is 
bad or good or both - as long as you have a dependence problem, 
you are wasting your life, just like I was. There are other 
languages and opportunities out there, go on, explore and have 
fun.
Jul 28
prev sibling next sibling parent reply Ethan <gooberman gmail.com> writes:
On Wednesday, 24 July 2019 at 05:03:16 UTC, Manu wrote:
 https://issues.dlang.org/show_bug.cgi?id=20012

 I need to know who is the crazy one here?
 I can't believe the idea that extern(C) functions being mangled 
 to
 un-knowable generated names is what any sane user would ever 
 expect.

 Surely extern(C) means extern(C)?

 I'd like a poll here...
I've only glanced at the thread last night through red eyes. But on Windows. Because most of my mangling experience is on Windows. If you extern( C ) and it doesn't get mangled to exactly the __traits( identifier ) and nothing else then it's being done wrong. You get duplicate symbols? Tough. I had a similar problem at Remedy with trying to use named modules and Binderoo to invoke a commonly named extern( C++ ) function. And of course all those functions were mangled exactly the same because it's extern( C++ ) and there's no parent namespace. I mentioned this in my DConf 2018 talk. My solution is outside of the scope of this thread.
Jul 24
parent reply Manu <turkeyman gmail.com> writes:
On Wed, Jul 24, 2019 at 7:20 AM Ethan via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Wednesday, 24 July 2019 at 05:03:16 UTC, Manu wrote:
 https://issues.dlang.org/show_bug.cgi?id=20012

 I need to know who is the crazy one here?
 I can't believe the idea that extern(C) functions being mangled
 to
 un-knowable generated names is what any sane user would ever
 expect.

 Surely extern(C) means extern(C)?

 I'd like a poll here...
I've only glanced at the thread last night through red eyes. But on Windows. Because most of my mangling experience is on Windows. If you extern( C ) and it doesn't get mangled to exactly the __traits( identifier ) and nothing else then it's being done wrong. You get duplicate symbols? Tough. I had a similar problem at Remedy with trying to use named modules and Binderoo to invoke a commonly named extern( C++ ) function. And of course all those functions were mangled exactly the same because it's extern( C++ ) and there's no parent namespace. I mentioned this in my DConf 2018 talk. My solution is outside of the scope of this thread.
Yeah, that's not what we're talking about. Stuff needs to do the right and proper thing, and when that's not what we want, we need power to override it. This is a case where extern(C) does weird shit that nobody would ever expect, and I'm being told to use the override to do the default thing. You write `extern(C) void fun();`, you expect a function called "fun", not "_D9__mixin153funv", why would anyone expect extern(C) to emit a D function? You can't write that in a `.h` file; the `15` on the end of "mixin" is a random serial number, it's impossible to know the function name, you literally can't declare it in a '.h' file! The rule is "extern(C) might mean what you want, and if it doesn't, we recommend you use pragma(mangle) to reconstruct the C symbol name... but don't forget to check if you need an underscore!"
Jul 24
parent Ethan <gooberman gmail.com> writes:
On Wednesday, 24 July 2019 at 21:32:11 UTC, Manu wrote:
 You write `extern(C) void fun();`, you expect a function called 
 "fun",
 not "_D9__mixin153funv"
Yes, that's what I expect. The similar problem I had with extern(C++) was that I should have expected it. extern(C++) works as expected but extern(C) doesn't? Strange things are afoot at the Circle K...
 The rule is "extern(C) might mean what you want, and if it 
 doesn't, we
 recommend you use pragma(mangle) to reconstruct the C symbol 
 name...
 but don't forget to check if you need an underscore!"
And this is what Binderoo is doing. In a roundabout way, that is. Defining extern(C) and extern(C++) everywhere gets in the way of just writing D code, so Binderoo generates C and C++ wrappers. Bonus with this approach: inlining is preserved. (Got some almost-finished code to correctly make C++ mangles for templated types, works for basically everything else so static linking should Just Work(TM) ).
Jul 24
prev sibling parent Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Wednesday, 24 July 2019 at 05:03:16 UTC, Manu wrote:
 https://issues.dlang.org/show_bug.cgi?id=20012

 I need to know who is the crazy one here?
 I can't believe the idea that extern(C) functions being mangled 
 to
 un-knowable generated names is what any sane user would ever 
 expect.

 Surely extern(C) means extern(C)?

 I'd like a poll here...
This has got to be one of the most duplicated issues in bugzilla. It's in there as 962 (12 years ago!), 4581, 6132, 7005, 12575, 15712, 15843, 17748, and now as 20012. There may even be more. As evinced by 4581 (which I filed in 2013), I'm on your side here. I also like Mike Franklin's idea of pragma(mangle, D) to handle the other cases. -- Simen
Jul 25