_argptr woes -- RFC from Walter

[Frits van Bommel]

kris wrote:
> Frits van Bommel wrote:
>> kris wrote:
>>> Indeed, although non-portable holds true only if you think in C 
>>> instead of D. According to the D documentation that code is written 
>>> "correctly", and thus it ought to be portable.
>>
>>
>> Assuming _argptr is a pointer and dereferencing it may be according to 
>> the spec as it is currently written, but that's not all the code does.
>> It also *increments* the pointer, at which time it _assumes_ all 
>> arguments are aligned at a multiple of int.sizeof (4). Even if varargs 
>> were entirely stack-based, that would likely break in the case of 
>> amd64 since the most natural alignment for most parameters would be 8 
>> (aka size_t.sizeof and (void*).sizeof).
[snip]
>> So even though GDC may be going against the spec here, I'm still 
>> pretty sure that piece of code is not portable.
> 
> That's why "correctly" was quoted, Frits.

I thought that to mean the code followed the spec to the letter but 
still failed, while IMHO it didn't follow the spec exactly (even though 
that wasn't the direct reason it failed on amd64).

 > I think you'll find a similar concern in the Phobos stdarg?

If used with GDC, yes. But the current implementation is just fine when 
it comes to DMD, since that only compiles for 32-bit x86-family processors.
You'll note that GDC distributes a different version :) (and has some 
special-case magic for the module).

 > There's a couple of issues going on here,
> and it would be useful to tease them apart first. Let's at least figure 
> out if the D doc is correct first, before we get all pedantic? :)

And how do you suggest we figure that out, except by waiting for Walter? 
And if that would be your suggestion, we may as well work ahead on the 
pedantic-ness until he comes by ;). (It's not like there's anything good 
on tv tonight over here...)