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

[Richard Smith]

On 20 August 2014 17:57, John McCall <rjmccall at apple.com> wrote:

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


FWIW, that was changed in C++11 (we're allowed to reject it now), but we
still shouldn't do so in unevaluated operands, because...

A lot of template
> metaprogramming tricks rely on overloads like this.


... of this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20140820/b92e015f/attachment-0001.html>