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

--- Comment #13 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Dicebot from comment #12)
> (In reply to Steven Schveighoffer from comment #11)
> > The issue here is -- we use the non-mangling "feature" of C calls to override type checking inside druntime. So even if something is extern(C) it can actually be implemented in D. That function may never need to be called or used in C code at all.
> 
> This is abuse and needs to be fixed. We have pragma(mangle) to override
> mangling.

I wasn't aware that we had a C mangling feature. We should change this ASAP, as I don't like the idea of specifying C functions for the sole purpose of escaping typechecking. If we fixed this, perhaps you have a better case for changing this.

> http://dlang.org/attribute.html#linkage is pretty clear on legitimate use cases this feature was designed for.

I don't think that's an exhaustive list of the uses. It only identifies one use -- calling existing C or C++ functions. But it can also be used to *implement* functions that are called from C (or D) code. When you implement an extern(C) function in D code, how should it treat a static array parameter? I think it would be more confusing to have this be different based on the extern(C).

> > Why shouldn't D support ref for C? All it is doing is auto-taking the address of the parameter, which maps perfectly to accepting a pointer or array argument.
> 
> Exactly because it is special case - it takes a language feature that does not have clear mapping to C feature and makes use of ABI details to work it as-is. It is not bad on its own but quite puzzling.

ref is sort of a weird thing to begin with. It automatically takes the address of the parameter, and passes that to the function, then the function dereferences it at every use. It's syntax sugar more than a storage class. And it extends beyond the ABI, because the entire function has to deal with it.

> > As another example, on a 32-bit system, C's long is 32-bit. But D's long is 64 bit. What to do here?
> > 
> > extern(C) foo(long x);
> 
> Ideally this should use C interpretation too but I recognize how it is totally impractical. This is not the case for static array arguments.

I see it as very similar. Two different interpretations of the same type keyword, in one language you have to tweak it a bit to fit the other, intransigent, existing language.

> You call tweaking own code (that makes use of undefined language area) to address compiler regression a right move?

It's not a regression if the breakage is intentional. It was not an accident that the compiler changed static arrays from being passed by reference to passed by value.

--

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

Mike Parker <aldacron@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldacron@gmail.com

--- Comment #14 from Mike Parker <aldacron@gmail.com> ---
(In reply to Dicebot from comment #7)
> The fact that `ref` parameters are allowed for extern(C) functions is even more bizzare than the fact that static array arguments crash programs. Need to check if it works, I would have never guessed to even try it.
> 

This is documented. See the section "Passing D Array Arguments to C Functions" at http://dlang.org/interfaceToC.html.

If anyone wants examples of existing code that will be broken by this, see Derelict. DerelictODE in particular, in which the matrix and vertex types are typedefed on the C side as fixed-size arrays and passed as such to all the functions that use them. Personally, I don't see the problem with prototyping such C functions with ref. I hope it *doesn't* change.

--

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

--- Comment #15 from Dicebot <public@dicebot.lv> ---
(In reply to Steven Schveighoffer from comment #13)
> > This is abuse and needs to be fixed. We have pragma(mangle) to override
> > mangling.
> 
> I wasn't aware that we had a C mangling feature. We should change this ASAP, as I don't like the idea of specifying C functions for the sole purpose of escaping typechecking. If we fixed this, perhaps you have a better case for changing this.

Are there any legit extern(C) declaration in druntime at all or everything needs to be updated? I'll do the PR.

--

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

Dicebot <public@dicebot.lv> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2
           Severity|regression                  |critical

--- Comment #16 from Dicebot <public@dicebot.lv> ---
(In reply to Mike Parker from comment #14)
> (In reply to Dicebot from comment #7)
> > The fact that `ref` parameters are allowed for extern(C) functions is even more bizzare than the fact that static array arguments crash programs. Need to check if it works, I would have never guessed to even try it.
> > 
> 
> This is documented. See the section "Passing D Array Arguments to C Functions" at http://dlang.org/interfaceToC.html.

I don't think complementary articles can be considered part of main spec - need to copy that definitions to `extern(C)` spec itself or at least place a direct link there.

> If anyone wants examples of existing code that will be broken by this, see Derelict. DerelictODE in particular, in which the matrix and vertex types are typedefed on the C side as fixed-size arrays and passed as such to all the functions that use them. Personally, I don't see the problem with prototyping such C functions with ref. I hope it *doesn't* change.

I am not proposing to prohibit ref-static-arrays, it would have been too much of a breakage indeed. But situation with plain static array arguments does sound too error-prone and impractical too keep. Think about it that way - because of this issue you can't just take C header and tweak it until it compiles as D code - it can still segfault at runtime after.

I will lower importance/priority though because of mentioned workaround with `ref` that makes it possible to preserve API safety

--

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

--- Comment #17 from Mike Parker <aldacron@gmail.com> ---
(In reply to Dicebot from comment #16)

> I am not proposing to prohibit ref-static-arrays, it would have been too much of a breakage indeed. But situation with plain static array arguments does sound too error-prone and impractical too keep. Think about it that way - because of this issue you can't just take C header and tweak it until it compiles as D code - it can still segfault at runtime after.
> 

Yes, I see. I got things mixed up. No argument there. That actually was a problem for me before I realized that ref worked.

--

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

--- Comment #18 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Dicebot from comment #16)

> I am not proposing to prohibit ref-static-arrays, it would have been too much of a breakage indeed. But situation with plain static array arguments does sound too error-prone and impractical too keep. Think about it that way - because of this issue you can't just take C header and tweak it until it compiles as D code - it can still segfault at runtime after.

If we can supersede druntime's usage of extern(C) for name mangling, I think
I'm OK with making any extern(C) function that accepts a non-ref static array
an error.

(In reply to Dicebot from comment #15)

> Are there any legit extern(C) declaration in druntime at all or everything needs to be updated? I'll do the PR.

I think it's for historical reasons mainly -- the original version of phobos (before druntime) had C implementations of some things, so the compiler always hooked with C mangling.

But I think this is a good question to ask the whole community. It could very well be that some people call the functions from C. However, I'm fairly certain most of the extern(C) declarations are simply for name mangling and getting around attribute requirements where needed.

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #19 from Walter Bright <bugzilla@digitalmars.com> ---
See:

https://github.com/D-Programming-Language/dmd/pull/4129

for D1.

--

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

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #20 from RazvanN <razvan.nitu1305@gmail.com> ---
(In reply to Andrej Mitrovic from comment #0)
> extern(C) void fail(int[4] x);
> extern(C) int[4] fail2();
> extern(C++) void fail3(int[4] x);
> extern(C++) int[4] fail4();
> 
> These should fail since C/C++ compilers always pass arrays by pointer to first element.

The last 2 declarations fails in today's compiler. I guess we can do the same for the first 2.

--

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

--- Comment #21 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

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

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

--