[cxx-abi-dev] Passing non-trivial types through ...

[Dennis Handly]

>From: Jason Merrill <jason at redhat.com>
>My proposal is that this would all be handled transparently by the 
>compiler, which knows which types need to be handled this way.

Ah.  I was reading va_arg and thinking just the "..." caller side.

>so my proposal would be incompatible with the current aCC behavior. 
Jason

Yes.  But I don't remember why we allowed it and what the user was doing on
the callee side, since we didn't provide any help.
Perhaps it was to a C function?  Or it goes back to cfront days.

Going back to aCC1 in 1997 we had:
Warning 400:  Passing an object with a copy constructor or virtual
function to a function with variable arguments is not yet implemented.
Object will be copied onto the stack instead of using a constructor.

We later changed it to:
Warning 400:  Passing an object with a copy constructor or virtual
function to a function with variable arguments has undefined behavior.
Object will be copied onto the stack instead of using a constructor.

>From: John McCall <rjmccall at apple.com>
>I agree that this is a problem; we shouldn't standardize" something that
>a vendor doesn't feel they can reasonably adopt.

True.

>Out of curiosity, how does aCC handle destruction of the argument?  Does
>it call the destructor at the argument's original location or its new
>location in the arguments area?
John.

No, that's what "bitwise" means.  :-)
No copy constructor or destructor.

>From: John McCall <rjmccall at apple.com>
>This is clearly the right way for any vendor who wants to accept non-POD
>variadic arguments to do it:  no solution involving memcpy can be
>correct for all types

Yes, except will the callee side be allowed to modify the object?