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 14:59:40 -0800 Organization: A noiseless patient Spider Lines: 59 Message-ID: <867e1y534z.fsf@linuxsc.com> References: <70391932-ccbc-4bc7-b693-881ab06eb6d3@googlegroups.com> <68359934-ade1-48cc-9055-5ccbc1371d64@googlegroups.com> <87sgkwo0ld.fsf@nosuchdomain.example.com> <86o8vb45v5.fsf@linuxsc.com> <87y2ufjj2u.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="25914"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/g8H6klzVP/Daw8Q4bCjICYurV2F/Wez4=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:4XAURQ83zXDpCDFvXg2gVAaEUq8= sha1:A+67P2Lry5awkHSjbNp+D1W0m0A= Xref: csiph.com comp.lang.c++:71270 Keith Thompson writes: > Tim Rentsch writes: > >> Keith Thompson writes: > > [...] > >>> 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. > > Do you have some reason for not telling us where that normative > text is? I know this is comp.lang.c++, but I suggest that the > presence of such text in the C standard, and its absence in the C++ > standard, is relevant to C++. I didn't have time for a longer posting. Also I don't think it's relevant for C++ because there is additional text in the C++ standard that explicitly makes such accesses be undefined behavior. >>> 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). > > Please consider telling us *how* it can be established constructively > rather than just being vague. My comments were consciously incomplete, but I don't think it's fair to call them vague, just incomplete. In any case I will try to post a more complete explanation sometime soon, in comp.lang.c.