Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: Don't be fooled by cpp.sh Date: Fri, 10 Jan 2020 09:51:37 -0800 Organization: None to speak of Lines: 54 Message-ID: <87y2ufjj2u.fsf@nosuchdomain.example.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="e12d2e2e5c667bdb5c60b35cd8bd7a9b"; logging-data="31263"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/2ec7ukTfdiN85pbkbCl5C" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:+sndk2kcU5AmfdgMY2lyhgmpgkk= sha1:A8BsleuRHGLHE/A5zhhjd3XfiO0= Xref: csiph.com comp.lang.c++:71264 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++. >> 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. [...] -- 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 */