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



--- Comment #10 from Don <clugdbug@yahoo.com.au> 2012-04-17 02:03:47 PDT ---
(In reply to comment #9)
> (In reply to comment #6)
> > > I'm not exactly talking about binding or calling convention, I'm more talking about types.  To me, the two are orthogonal.
> > 
> > Whereas I would argue that since you're declaring a C function, it should be a _C_ function and therefore not include features which C doesn't have. The only reason that I think that permitting pure and nothrow on C functions makes any sense is out of pure necessity.
> 
> No.  An extern(C) function does not mean it's a C function.  It just means it has C linkage.  See here: http://dlang.org/attribute.html#linkage
> 
> extern(C) has nothing to do with parameters, only calling conventions.

I don't understand that statement. Do you mean 'parameters, only name mangling"
? If so, that that isn't true.
On 32-bit x86 Windows,

extern(D) void foo(int x)

passes x in the EAX register.

extern(C) void foo(int x)

passes x on the stack.
It's not just a name mangling issue.

The confusion comes because there are some druntime functions which use C name
mangling but the extern(D) calling convention! This is not true of all
extern(C) functions.

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

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



--- Comment #11 from Steven Schveighoffer <schveiguy@yahoo.com> 2012-04-18 05:21:34 PDT ---
(In reply to comment #10)
> (In reply to comment #9)
> > No.  An extern(C) function does not mean it's a C function.  It just means it has C linkage.  See here: http://dlang.org/attribute.html#linkage
> > 
> > extern(C) has nothing to do with parameters, only calling conventions.
> 
> I don't understand that statement. Do you mean 'parameters, only name mangling" ? If so, that that isn't true.

No, I mean the extern(C) designates linkage and calling convention, it doesn't affect the parameters or qualifiers for those parameters.  It also doesn't mean C is the language used for implementation.

In other words, if the language implementing the function implements/understands immutable, then why should it be disallowed to pass immutable to an extern(C) function?  Same goes for ref, scope, in, out.

If something is passed in a register vs on the stack, that's part of the calling convention, no?  It doesn't actually affect the parameter type or its properties.  That's what I meant for 'nothing to do with parameters'.  Maybe that was a misleading statement...

> The confusion comes because there are some druntime functions which use C name
> mangling but the extern(D) calling convention! This is not true of all
> extern(C) functions.

Wait, how can a function marked extern(C) not use C calling convention?  Are these special-cased compiler functions?  If that's the case, I don't see how those exceptions should affect the rules of extern(C), it doesn't affect anything outside the compiler/runtime.

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

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



--- Comment #12 from Don <clugdbug@yahoo.com.au> 2012-04-18 10:59:56 PDT ---
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > No.  An extern(C) function does not mean it's a C function.  It just means it has C linkage.  See here: http://dlang.org/attribute.html#linkage
> > > 
> > > extern(C) has nothing to do with parameters, only calling conventions.
> > 
> > I don't understand that statement. Do you mean 'parameters, only name mangling" ? If so, that that isn't true.
> 
> No, I mean the extern(C) designates linkage and calling convention, it doesn't affect the parameters or qualifiers for those parameters.  It also doesn't mean C is the language used for implementation.

But C doesn't HAVE a calling convention for non-C types!

extern(C) void foo( void delegate() dg)
DOES NOT MAKE SENSE. It's not C, it's something else.

With one exception: if extern(C) means only "mangle as a C function" then it is well defined for everything (because C doesn't mangle types). But I think everybody expects it to include calling convention as well.

There are really two options:
(1) disallow non-C parameters in extern(C) functions
(2) extend the definition of extern(C) to specify what happens with non-C
parameters.

> > The confusion comes because there are some druntime functions which use C name
> > mangling but the extern(D) calling convention! This is not true of all
> > extern(C) functions.
> 
> Wait, how can a function marked extern(C) not use C calling convention?  Are these special-cased compiler functions?

Yes. In those special cases, extern(C) just means C name mangling. I think that's an indicator of how vague the spec is.

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

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



--- Comment #13 from Steven Schveighoffer <schveiguy@yahoo.com> 2012-04-18 11:23:14 PDT ---
(In reply to comment #12)
> 
> But C doesn't HAVE a calling convention for non-C types!
> 
> extern(C) void foo( void delegate() dg)
> DOES NOT MAKE SENSE. It's not C, it's something else.

I would expect that in this case, whatever rules are established for passing custom types of size dg.sizeof would apply.  I would never have guessed that calling convention concerned itself with types or how to pass specific types. I thought it had to do only with where the arguments are placed, what order they are passed, etc.

But does C even *have* a defined calling convention?  I mean even on the same platform (Microsoft CRT) you can use any of 6 calling conventions http://msdn.microsoft.com/en-us/library/984x0h58%28v=vs.80%29.aspx

I also note that none of those specify anything about how types affect the calls.

> There are really two options:
> (1) disallow non-C parameters in extern(C) functions
> (2) extend the definition of extern(C) to specify what happens with non-C
> parameters.

I think option 1 is too damaging to current code.  Option 2 is fine, as long as it doesn't get into describing the actual calling convention (which is platform specific).  e.g. say ref parameters are passed as if the address of the parameter was passed.

> Yes. In those special cases, extern(C) just means C name mangling. I think that's an indicator of how vague the spec is.

That sounds unreasonably confusing.  What benefit do we have for specially treating those functions?  I'd rather see a pragma(nomangle), or have the functions actually use C calling convention.

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

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



--- Comment #14 from Don <clugdbug@yahoo.com.au> 2012-04-18 21:29:37 PDT ---
(In reply to comment #13)
> (In reply to comment #12)
> > 
> > But C doesn't HAVE a calling convention for non-C types!
> > 
> > extern(C) void foo( void delegate() dg)
> > DOES NOT MAKE SENSE. It's not C, it's something else.
> 
> I would expect that in this case, whatever rules are established for passing custom types of size dg.sizeof would apply.

There's no such rule. Currently DMD casts a delegate to a long (for 32 bits) or
a cent (for 64 bits) when passing it as a parameter. If it passed it as a
struct, the convention would be different.
So there are a couple of reasonable choices, but they aren't documented.

> But does C even *have* a defined calling convention?  I mean even on the same platform (Microsoft CRT) you can use any of 6 calling conventions http://msdn.microsoft.com/en-us/library/984x0h58%28v=vs.80%29.aspx

Yes, it's defined, though it is OS dependent. It's consistent among all Windows compilers (excluding gcc, which refuses to cooperate).

Note that (for example) the Windows calling convention doesn't support varargs.
So in the Windows API everything used extern(Windows) except for a single
function which used extern(C).
There is however no defined calling convention for C++.


> > There are really two options:
> > (1) disallow non-C parameters in extern(C) functions
> > (2) extend the definition of extern(C) to specify what happens with non-C
> > parameters.
> 
> I think option 1 is too damaging to current code.  Option 2 is fine, as long as it doesn't get into describing the actual calling convention (which is platform specific).  e.g. say ref parameters are passed as if the address of the parameter was passed.

You _always_ need to know what it is doing. There may need to be a platform-specific description. It can describe things in terms of the C convention (eg, "delegates are passed as a struct" or "array slices are passed as a unsigned long long".

> > Yes. In those special cases, extern(C) just means C name mangling. I think that's an indicator of how vague the spec is.
> 
> That sounds unreasonably confusing.  What benefit do we have for specially treating those functions?  I'd rather see a pragma(nomangle), or have the functions actually use C calling convention.

I think it's just a hack.

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