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

[John McCall]

On Aug 20, 2014, at 5:13 PM, Dennis Handly <dhandly at cup.hp.com> wrote:
>> From: Jason Merrill <jason at redhat.com>
>> On 08/13/2014 08:36 PM, Jason Merrill wrote:
>>>>> 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
>>> 
>>> 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 <rjmccall at apple.com>
>>> 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.