On 08/13/2014 08:04 PM, Dennis Handly wrote:
From: Jason Merrill <[email protected]>
so my proposal would be incompatible with the current aCC behavior.

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.

G++ 3.1 and earlier did the same bitwise copy, which makes sense for a C legacy definition of va_arg like GCC had before 3.0:

#define va_arg(AP, TYPE)                                              \
 (AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (TYPE)),   \
  *((TYPE *) (void *) ((char *) (AP) - __va_rounded_size (TYPE))))

From: John McCall <[email protected]>
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

Yep. The only question is whether it's better, for code that is in a gray area of the standard, to stick with the broken historical practice or do something more correct.

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

Whether the result of va_arg is modifiable (or even an lvalue) is unspecified. In this case it would be.

Jason

_______________________________________________
cxx-abi-dev mailing list
[email protected]
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev

Reply via email to