[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Fri Nov 7 12:21:46 PST 2014


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

--- Comment #12 from Dicebot <public at 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?

--


More information about the Digitalmars-d-bugs mailing list