On Aug 20, 2014, at 5:13 PM, Dennis Handly <[email protected]> wrote: >> From: Jason Merrill <[email protected]> >> On 08/13/2014 08:36 PM, Jason Merrill wrote: >>>>> 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. > >> Since there is incompatible existing practice and the code is only >> conditionally-supported anyway, perhaps sticking with existing practice >> is the right answer even though it breaks the object model. > >> On the other hand, perhaps since the code is only >> conditionally-supported, compatibility with existing practice isn't as >> important. > Jason > > I wrote a better test case to test both caller and callee sides and also > looked up the warning and found a test case from an important customer. > So someone is using it. :-) > >> From: John McCall <[email protected]> >>> On the other hand, perhaps since the code is only conditionally-supported, >>> compatibility with existing practice isn't as important. > >> I'’m not sure we really do have “existing practice” on this. Dennis, I >> apologize if I’m misunderstanding you, but it sounds like you consider >> this to be undefined behavior > > Well the message indicates it. And it won't work in all cases. I.e. > if you put the address inside itself, that won't match. > > But I did look up the warnings and found a test case from an important > customer. > > (I'm not sure if there were other customers that had an actual but > different use of this?) > > But looking real close at it, this won't be a problem, since used in > template metaprogramming:
Oh, yes, that’s definitely a language requirement: you can’t outright reject this construct if it’s not potentially-evaluated. A lot of template metaprogramming tricks rely on overloads like this. But it doesn’t affect whether you consider it undefined behavior when it *isn’t* potentially evaluated. John. _______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
