Re: Union C++ standard

On 2021-11-28, David Brown <david.brown@hesbynett.no> wrote:
> On 28/11/2021 13:51, Derek Jones wrote:
>> David,
>>
>>> In C, type-punning via unions is allowed (i.e., fully defined behaviour
>>
>> That is not true.  Writing into one member and then reading from
>> another member is undefined behavior.
>
> No, it is correct. It would be helpful if you looked at the full
> published standards, or (as most people do, since they are free) the
> final pre-publishing drafts. In particular, they contain the footnotes
> that appear to be missing in the format you linked here. Footnotes are
> not part of the normative text, but are added for clarification.


Not being normative means that anything that looks like a requirement
that is in a footnote is not actually a requirement.


Footnotes can only clarify requirements that are not themselves in a
foonote; they can't add new requirements.


If you cannot infer the existence of a requirement while ignoring all
foonotes and examples, it isn't there.


> These quotations are from C18 (draft N2346), which is the current C
> standard (until C23 is finalised). They have not changed since C99,
> when the footnote was added without a change to the normative text.


I have a copy of C99 (the final thing from ANSI, not a draft); I do not
see any such footnote; the paragraph has no footnotes.


> This means that as far as the C committee was concerned, using unions
> for type-punning has always (since standardisation) been valid in C,


Note that the "trap representation" terminology didn't exist prior to
C99, so any footnote referencing such a thing cannot possibly reflect
any intent about what C was going back to before standardization,
let alone some new footnote since C99.


> they realised that the text was unclear and thus added the footnote.
> (Arguably, since C90 did not clearly state that type-punning was
> defined, the behaviour was in fact undefined - though probably all C
> compilers allowed the behaviour.)


The concept of trap representations adds nuance to the requirements
for accessing objects; it doesn't make everything defined.


The trap concept is used to create a new (in C99) model why accessing an
object a field of "unsigned char" is okay: the unsigned char type has no
trap representation: all combinations of bit patterns give rise to a
valid value.


For instance, if we have a union like this:


    union u {
          int x;
          unsigned char y[sizeof (int)];
    }


then certain requirements can be inferred if we store x and access y[0],
based on knowing the implementation's parameters, like size and
representation of the integer and byte order.


I don't believe that the footnote you quoted gives any special blessing
to union-based type punning over pointer-based type punning. It just
clarifies the fact that unions are type punning, subject to the same
requirements as any other type punning. It points the reader to section
6.2.6 where the real requirements are, using which all instances of
type punning are to be interpreted.


--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Return to the comp.compilers page.
Search the comp.compilers archives again.