[cfe-dev] http://llvm.org/bugs/show_bug.cgi?id=11462

[Richard Smith]

On Fri, December 2, 2011 21:48, Jeffrey Yasskin wrote:
> On Fri, Dec 2, 2011 at 1:21 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>
>> On Fri, Dec 2, 2011 at 1:04 PM, Jeffrey Yasskin <jyasskin at googlers.com>
>> wrote:
>>
>>> FWIW, I think a better solution for the library issue would be for
>>> clang to provide an attribute saying "ignore the rule in [intro.object]p6,
>>> and allow this member to have 0 size." Doing this would allow
>>> possibly-empty types to be used directly as members, rather than
>>> obfuscating the code by forcing them into base classes or tuples. Perhaps
>>> spell the attribute [[may_be_empty]] or
>>> [[may_have_same_address_as_other_members]].
>>>
>>
>> If we did that, the user could observe two final objects with the same
>> address... which shouldn't be possible, I think.

It is possible.

struct A final { int n; };
struct B final { A a; };

> Is that more important for final objects than other kinds of objects?
> Arguably, even the attribute shouldn't be enough to put two objects of
> the same type at the same address, which is the restriction used for base
> classes.

Technically, doing this appears to violate [intro.object]p6. However, the
footnote to that paragraph allows the implementation (and hence the standard
library) to break the rule in some cases: "Under the “as-if” rule an
implementation is allowed to store two objects at the same machine address or
not store an object at all if the program cannot observe the difference." If
the program can't legitimately form a pointer to the other member of the
container with which the empty allocator would share an address, the
optimization seems to be conforming.

Richard