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

Dicebot <public@dicebot.lv> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |industry
           Priority|P2                          |P1
             Status|RESOLVED                    |REOPENED
                 CC|                            |public@dicebot.lv
         Resolution|WONTFIX                     |---
           Severity|normal                      |regression

--- Comment #3 from Dicebot <public@dicebot.lv> ---
Reopining it and marking as critical regression issue. Also with "industry" keyword.

This is regression from D1 behaviour that makes all of our existing extern(C) bindings segfault when compiled with D2 compiler. Only workaroun possible to replace it with pointer arguments everywhere, losing important chunk of type safety in process.

However I don't like compilation failure here either. extern(C) functions must comply to C ABI and thus pass static arrays by pointer even if normal D functions do that by value.

Walter original reasoning about breaking original code is completely unapplicable here as any code that currently compiles with this pattern will segfault at runtime anyway. There can't be any legit working code out there to break.

--

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

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com

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

> However I don't like compilation failure here either. extern(C) functions must comply to C ABI and thus pass static arrays by pointer even if normal D functions do that by value.

Wouldn't ref work? It seems to work for me.

-Steve

--

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

--- Comment #5 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Steven Schveighoffer from comment #4)
> (In reply to Dicebot from comment #3)
> 
> > However I don't like compilation failure here either. extern(C) functions must comply to C ABI and thus pass static arrays by pointer even if normal D functions do that by value.
> 
> Wouldn't ref work? It seems to work for me.

Sorry, I quoted the wrong part of your post, it should have been:

(In reply to Dicebot from comment #3)
> This is regression from D1 behaviour that makes all of our existing extern(C) bindings segfault when compiled with D2 compiler. Only workaroun possible to replace it with pointer arguments everywhere, losing important chunk of type safety in process.

--

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

--- Comment #6 from bearophile_hugs@eml.cc ---
(In reply to Dicebot from comment #3)

> However I don't like compilation failure here either. extern(C) functions must comply to C ABI and thus pass static arrays by pointer even if normal D functions do that by value.

I think that a compilation failure is better because it avoids to introduce a special case in the D language. Special cases cause problems, even when they look a little handy.

--

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

--- Comment #7 from Dicebot <public@dicebot.lv> ---
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.

In general we have "looks like C, works like C" slogan. My point is that this is especially important with function _explicitly_ marked as "should work like C" - any mismatch between extern(C) ABI and real C ABI is an important bug.

--

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

--- Comment #8 from Dicebot <public@dicebot.lv> ---
(In reply to bearophile_hugs from comment #6)
> I think that a compilation failure is better because it avoids to introduce a special case in the D language. Special cases cause problems, even when they look a little handy.

There is no special case here - extern(C) by definition must implement C ABI of argument passing. It is simply out of D language domain ones arguments are passed.

--

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

--- Comment #9 from bearophile_hugs@eml.cc ---
(In reply to Dicebot from comment #8)

> There is no special case here - extern(C) by definition must implement C ABI of argument passing. It is simply out of D language domain ones arguments are passed.

D fixed-size arrays are values. C language lacks those values, so I think D doesn't have a C ABI to respect.

--

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

--- Comment #10 from Dicebot <public@dicebot.lv> ---
C has static arrays. C allows passing static arrays as function arguments. HOW it is passing them is defined by ABI and D rules are irrelevant here.

--

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

--- Comment #11 from Steven Schveighoffer <schveiguy@yahoo.com> ---
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.

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.

I think the important pieces of the C ABI to implement are where parameters go, and the lack of name mangling. Other than that, how to pass certain types is more fuzzy.

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);

Clearly, it's not too important the type of x, but how big it actually is. This leads one to simply type it as int instead, and move on. This hasn't really caused tremendous issues or difficulties. I think really the crux of the push for this bug is more that D2 behaves differently vs. D1 than D2 implements the C ABI incorrectly.

Note, I remember the ref trick when we moved to passing static arrays by value, for the system call pipe. This takes an int[2]. To switch this to a pointer not only breaks existing code, but we lose the type requirement that it should be exactly 2 elements wide. The ref solution worked, so we employed it, and I think it was the right move.

--

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

--- Comment #12 from Dicebot <public@dicebot.lv> ---
(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.

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

> 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.

> 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.

> Note, I remember the ref trick when we moved to passing static arrays by value, for the system call pipe. This takes an int[2]. To switch this to a pointer not only breaks existing code, but we lose the type requirement that it should be exactly 2 elements wide. The ref solution worked, so we employed it, and I think it was the right move.

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

--