Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c++
Subject: Re: Don't be fooled by cpp.sh
Date: Fri, 03 Jan 2020 10:29:18 -0800
Organization: None to speak of
Lines: 54
Message-ID: <87sgkwo0ld.fsf@nosuchdomain.example.com>
References: <70391932-ccbc-4bc7-b693-881ab06eb6d3@googlegroups.com> <qumbtt$7jr$1@dont-email.me> <qunkhr$hou$1@gioia.aioe.org> <68359934-ade1-48cc-9055-5ccbc1371d64@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="53f826ccc04a364acdb5be3b5e1fcc0d"; logging-data="27063"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/caBm+79xlFboNRsgY4JPr"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
Cancel-Lock: sha1:VL8bu1kX1xnNNlUVWdtoZqCv7mo= sha1:Mv9UeA6OZA4In8oQs+EkLehX7PI=
Xref: csiph.com comp.lang.c++:71040

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
> So - what general rule does the C++ standard state that covers the
> specific case if reading from a member of a union that is not
> currently the active one?
> Keep in mind that the relevant clause is says that "the value
> contained in the object indicated by the glvalue is the prvalue
> result." (7,1p3). The members of a union are considered to be
> distinct objects that happen to have the same location in memory.
> Therefore,  if the member being read is not the active one, there is
> no value contained in that object, and 7.1p3 doesn't apply.
> The C standard contains a non-normative footnote which claims that
> the contents of that memory get reinterpreted as if they contained an
> object of the same type as the lvalue used to read it. The C++
> committee has known about the C wording for more than two decades
> now, and has chosen to not incorporate similar wording in any version
> of the C++ standard. I think we can safely assume that this omission
> constitutes a deliberate difference between the two languages,
> probably due to the greater importance of type safety in C++. It's
> hard to imagine anything more type-unsafe than type punning.

That non-normative footnote does raise an interesting point, though.

N1570 (C11) 6.5.2.3 footnote 95:

    If the member used to read the contents of a union object is
    not the same as the member last used to store a value in the
    object, the appropriate part of the object representation of
    the value is reinterpreted as an object representation in the
    new type as described in 6.2.6 (a process sometimes called
    "type punning"). This might be a trap representation.

The Introduction to the C standard says:

    Footnotes are provided to emphasize consequences of the rules
    described in that subclause or elsewhere in this International
    Standard.

So the footnote effectively asserts that its conclusions are implied
by normative rules, though it's not clear that there's any normative
text in the C standard that supports the claim in this footnote.
If the normative requirements in C++ are sufficiently similar to
those in C, one could argue that the assertion in that footnote is
as valid for C++ as for C.

(My own conclusion is that the lack of supporting normative text is a
flaw in the C standard.  It should make a clear normative statement
about the behavior of type punning using union members.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    [Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */