Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c++
Subject: Re: Union type punning in C++
Date: Mon, 13 Jan 2020 09:01:49 -0800
Organization: A noiseless patient Spider
Lines: 62
Message-ID: <86r203guiq.fsf@linuxsc.com>
References: <kl6PF.88068$CSS.31003@fx01.dcg> <quluvv$10pp$1@gioia.aioe.org> <490dd5d6-fb8a-482b-a88d-550b8a4defd0@googlegroups.com> <86d0bq2fmi.fsf@linuxsc.com> <140b2e3a-cc88-45f9-a292-efd471e3c789@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="3f3153150e66f3eb10123de9932e6704"; logging-data="9004"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+2uOvmUC23RWdt0vh01bkwG7yDIh5SvqM="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:mIo+bmeCA+iKHyeSbkuQLU6DUUU= sha1:n63rxtTmOgCg28Z6BfgAErvmIY8=
Xref: csiph.com comp.lang.c++:71307

Tiib writes:

> On Saturday, 11 January 2020 17:10:43 UTC+2, Tim Rentsch  wrote:
>
>> Tiib writes:
>>
>>> On Friday, 3 January 2020 01:39:54 UTC+2, Chris M. Thomasson  wrote:
>>>
>>>> On 1/1/2020 11:24 AM, Mr Flibble wrote:
>>>>
>>>>> Undefined behaviour aside is C++ union type punning an acceptable hack
>>>>> or not, given that it is legal in C?
>>>>> If it works on all the compilers I care about does it really matter that
>>>>> it is *currently* classed as undefined behaviour?
>>>>> I would say that everyone has "secretly" fucking done it some time or
>>>>> other so the C++ Standards Committee should get there act together and
>>>>> legalize it like it has been in C.
>>>>> Can anyone provide a straight answer to this?
>>>>
>>>> Is there some cryptic hidden thing in the standard that just might
>>>> "allow" for the following code to run without ub?
>>>
>>> Possibly.
>>>
>>>> ___________________________
>>>> #include <iostream>
>>>>
>>>> struct base
>>>> {
>>>>      int p0;
>>>> };
>>>
>>> Standard layout classes have lot of additional guarantees.
>>>
>>>> struct object_0
>>>> {
>>>>      base b;
>>>>      int p0;
>>>> };
>>>
>>> Standard layout with common initial sequence with base.
>>
>> Unless I'm missing something the two struct types base and object_0
>> don't have a common initial sequence (or we might say the common
>> initial sequence is the empty set).  The first member of base is of
>> type int.  The first member of object_0 is of type base.  These two
>> types, int and base, are not layout-compatible:  they are not the
>> same type;  they are not layout-compatible enumerations;  and they
>> are not layout-compatible standard-layout class types.  Hence there
>> is no common initial sequence.
>
> Address of standard layout object and its first element is required to
> be same so standard layout struct x and other struct that has  x as
> first element have the whole x as common initial sequence.

The first member of struct base is of type 'int'.  The first member of
struct object_0 is of type 'base'.  The two types, 'int' and 'base',
are not layout compatible.  Do you agree or disagree?

If you agree, then because the types of those members are not layout
compatible, those members are not part of a common initial sequence.
Do you agree or disagree?