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

[John McCall]

On Aug 13, 2014, at 5:04 PM, Dennis Handly <dhandly at cup.hp.com> wrote:
>> 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.

I’d be happier if you disavowed the previous implementation of the
extension, of course. :)

>> 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?
> 
> No, that's what "bitwise" means.  :-)
> No copy constructor or destructor.

So, you suppress destruction completely of the argument, and it potentially
goes undestructed?

>> 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?

I don’t see how we can prevent it.  Even if va_arg returns an r-value
(i.e. if the compiler generates an implicit copy out of the “reference” that
we pass through variadics), that copy constructor could mutate the
object.  And it doesn’t really matter anyway — the temporary whose
address is passed would still be live in the caller’s frame.

John.