Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: lvalues from the ternary op Date: Fri, 24 Feb 2017 12:42:03 -0800 Organization: None to speak of Lines: 95 Message-ID: References: <2f20253f-9ce6-4dcd-82e7-2fcdc2eae5b0@googlegroups.com> <698d5687-fb5e-488d-841e-99991d26c314@googlegroups.com> <87y3xqn0fe.fsf@bsb.me.uk> <151d7ce8-f628-4f42-a2a3-c92a8bb7e682@googlegroups.com> <87a8a5mgte.fsf@bsb.me.uk> <276589b7-b156-44a0-baeb-551aa95691a2@googlegroups.com> <00c2c595-687f-4f18-a7a6-a076e8253e71@googlegroups.com> <7cf3d284-16e8-4f6a-8f3a-b62b8fbcd9c5@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="6b4ae51bb3e4b1095130ab23a20a425a"; logging-data="10696"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18mFLTzNdp/m/o6/IR4EmHL" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:GKpbWpHXBHfMiTfU2aIB3GX5pxU= sha1:BlC5ZWivBWdE+KtEqJ4rS2kGdQU= Xref: csiph.com comp.lang.c:104639 supercat@casperkitty.com writes: > On Friday, February 24, 2017 at 9:58:56 AM UTC-6, Tim Rentsch wrote: >> The problem you're having now is that your conclusions are not >> consistent with everyone else's. Until you learn to express >> yourself in a way that communicates effectively with other >> people, /and vice versa/, that problem is not going to go away. >> A tall order, I know, but there it is. > > The following questions assume the following declaration is in scope, and > for questions about code, assume the scope is within some function and is > executed. > > union { unsigned u; float f; } uf; > > True or false: the Standard specifies as a runtime constraint that stored > value of an object of type "float" may not be accessed with an lvalue of > type "unsigned". Because this is a runtime constraint, the Standard > allow implementations to do anything whatsoever if code violates it. Such > permission overrides anything else in the Standard that would otherwise > define the behavior of the code. False. The term "runtime-constraint", introduced in C11, applies only to calls to library functions specified in the optional Annex K. I think you meant (or should have meant) "undefined behavior". If you'd like to try again, please cite the wording in the standard that says the behavior is undefined (if there is such wording). In fact, I strongly suggest you support each of your true/false statements with a direct citation of the standard (N1570 is fine). That will make it easier for the rest of us to follow along, and I for one have a fairly low threshold for how much effort I'm willing to put into this. > True or false: the Standard specifies that the above declaration will, among > other things, create an object of type "float" which is stored within "uf", > and such object will exist as long as containing "uf" object exists. There might be some question of whether the float object uf.f "exists" when the unsigned member uf.u is the one that was most recently written. I am not attempting here to answer any such question, just observing that this is a point that calls for extra clarity. > True or false: the Standard specifies that the expression "uf.u" will > is an lvalue of type "unsigned". I presume you meant "is" rather than "will is". I agree that the statement is true, but I'm being cautious because you've misused the term "lvalue" before. > True or false: the Standard allows an implementation to process the > statement "uf.u = 4;" in a way that writes to the stored value of the float > value stored within "uf". I suggest wording this more clearly. One can write to an object, not to a value; writing to an object updates the value that's stored in that object. > True or false: the Standard allows an implementation to process the > statement "uf.u = 4;" in a way that would cause a stored value of type > "float" to be accessed using an lvalue of type "unsigned", violating a > runtime constraint. Again, you're misusing the term "runtime constraint". > True or false: if any of the ways in which a conforming implementation > could process an action invoke UB, the action itself invokes UB. I think there's a statement in the standard that's similar to that, though I'm not at all certain about it. If there is, I suggest citing it directly so we can judge whether your summary is accurate. [snip] It's quite possible that the standard's wording on union members is internally inconsistent (that "quite possible" is mostly reflective of my current state of ignorance on the matter). One particular question I'm curious about is whether the footnote in 6.5.2.3: 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. can be inferred from the normative wording of the standard. (It clearly represents the intent of the committee. The question is whether that intent is sufficiently clearly stated in normative text.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"