--- Comment #14 from Don <clugd...@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
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
> it doesn't get into describing the actual calling convention (which is
> 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: -------