>From: Jason Merrill <[email protected]> >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 <[email protected]> >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 <[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 Yes, except will the callee side be allowed to modify the object? _______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
