[cxx-abi-dev] The magic of uncalled copy constructors; documenting the bug

[Richard Smith]

On 12 February 2014 08:55, John McCall <rjmccall at apple.com> wrote:

> On Feb 10, 2014, at 12:39 PM, Richard Smith <richardsmith at google.com>
> wrote:
>
> On 10 February 2014 09:32, John McCall <rjmccall at apple.com> wrote:
>
>> On Feb 9, 2014, at 6:17 PM, Richard Smith <richardsmith at google.com>
>> wrote:
>>
>> On 9 February 2014 05:37, Hubert Tong <hstong at ca.ibm.com> wrote:
>>
>>> Core Issue 1590 mentions that the trivial copy or move constructor
>>> should be non-deleted and accessible.
>>> Replacing the pair of copy constructors below with private, deleted copy
>>> and move constructors seems to make GCC avoid the "magic" copy, but not
>>> Clang.
>>> Which compiler has the preferred behaviour?
>>>
>> I think GCC does, whereas Clang obeys the current description of the ABI.
>>
>> Under the current wording of core issue 1590, we're not allowed to
>> perform a 'trivial' copy here. I think we should update the ABI document
>> (in 3.1.1/1) to make this work (perhaps something equivalent to replacing
>> "non-trivial" with "non-trivial, non-public, or deleted" each time it
>> occurs).
>>
>>
>> gcc’s rule appears to just be “non-trivial or deleted”, which I think is
>> reasonable for the ABI to adopt.  Would you like to write up a proposal for
>> that?
>>
>
> Sure.
>
>
>> “Accessible” does not mean “public”.  That’s a standards bug: we need to
>> be able to decide the ABI signature of a function at its point of
>> declaration, not have it be dependent on whether there exist (or might
>> exist) calls to it which would not be allowed to use a privately-defaulted
>> trivial copy constructor.
>>
>
> I don't see anything wrong with the standard here. Inaccessible implies
> non-public for these members (because they're not inherited from a base
> class), so the ABI can look for a public special member where the standard
> says any accessible special member is permitted to be called.
>
>
> Inaccessible does imply non-public, but accessibility in general is
> context-sensitive.
>
> Are you asking for the ABI rule to actually be “non-public, non-trivial,
> or deleted”?  I agree that that’s what the standard is requesting, because
> it’s the only way we can guarantee at the point of declaration of a
> function that all callers will be able to access the special member.
>  However, it’s not the current practice of any compiler, probably because
> we generally try quite hard to prevent access control from affecting the
> ABI, e.g. because it seems unfortunate for things like "#define private
> public” to actually break binary compatibility.  (I’ll grant that it’s
> legal under the standard, and it might also already affect the ABI in
> corner cases by making a base class suddenly POD.)
>

 This only makes a difference if the function is trivial and not deleted.
So we're *only* talking about the case of:

struct S {
  S(const S&) = default;
};

versus

struct S {
private:
  S(const S&) = default;
};

... and yes, I think we should be allowed to make technical copies in the
first case, and I think we should *not* be allowed to do so in the second
case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20140213/802e6621/attachment.html>