Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c++ Subject: Re: Don't be fooled by cpp.sh Date: Fri, 10 Jan 2020 08:46:06 -0800 Organization: A noiseless patient Spider Lines: 69 Message-ID: <86o8vb45v5.fsf@linuxsc.com> References: <70391932-ccbc-4bc7-b693-881ab06eb6d3@googlegroups.com> <68359934-ade1-48cc-9055-5ccbc1371d64@googlegroups.com> <87sgkwo0ld.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="7b070c0766e341d0df2bb5814a4c869f"; logging-data="2755"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18A8dna3LoLFC+Yk7Jq/ItRc35clxgX+Iw=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:HyNJwLUehmAddCDyLpYduoDPgAQ= sha1:arTTbNv8RnfwT7bKjPcs7I9xc7A= Xref: csiph.com comp.lang.c++:71263 Keith Thompson writes: > James Kuyper 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. In my reading of the C standard, there is normative text that establishes the assertion in the 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. The C++ standard clearly does not admit the same reasoning as the C standard in this regard, because the definedness of accessing union members is tied (in C++) to their lifetimes, and the lifetimes are not the same in C++ as they are in C. In C++, the "UB-ness" of accessing a different union member can be established constructively (ie, it is not just a question of a definition being omitted). > (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.) There is normative text that implies what the footnote says. That isn't as obvious as some people might like, so it would be good if the behavior were described more directly, for clarity. But the behavior is described more directly: it is described in this very footnote.