Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Ike Naar Newsgroups: comp.lang.c Subject: Re: lvalues from the ternary op Date: Mon, 23 Jan 2017 17:59:33 -0000 (UTC) Organization: A noiseless patient Spider Lines: 33 Message-ID: References: <8737kned1h.fsf@bsb.me.uk> <8737klapvv.fsf@bsb.me.uk> <877f6alefh.fsf@bsb.me.uk> <37926c90-a12c-4854-8daf-bbbb6fb36dc0@googlegroups.com> <5ff45dfe-0bd4-479b-a017-64da7de9ae0d@googlegroups.com> <5e9cc790-7d79-4ce3-8101-0d423e8f2a46@googlegroups.com> <09829387-6df4-4cc8-a044-e71b7f8d44dd@googlegroups.com> <734bc6bf-9879-4e71-9f54-f27ec92fb50e@googlegroups.com> <2f20253f-9ce6-4dcd-82e7-2fcdc2eae5b0@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Date: Mon, 23 Jan 2017 17:59:33 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="b8c8cd1c769c04c648bafe5582ffab25"; logging-data="13541"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+r2dBxwZ+DCUDRf6RJM+S/" User-Agent: slrn/0.9.9p1 (NetBSD) Cancel-Lock: sha1:kIXho/nB+SZrtnlzuaYuP5F8SS0= Xref: csiph.com comp.lang.c:102378 On 2017-01-23, supercat@casperkitty.com wrote: > Given "union u { uint32_t x; float y; } u;", if both u.x and u.y are objects, > which of the following can be said about the code "u.x = 1;": > > 1. The thing to the left of the equals is something other than an > lvalue of type "uint32_t". > > 2. The code does not access the stored value of a "float" object. > > 3. The code invokes Undefined Behavior because it uses an lvalue of type > uint32_t to access the value of a float object. > > I would regard possibility #3 as preposterous, since it would suggest that > any union which contained anything other than a combination of alias- > compatible types (e.g. int32_t and uint32_t) would be completely unusable > for any purpose. > > In order to make unions workable *at all*, it's necessary to either adjust > the meaning of "lvalue" such that u.x is something other than a simple > lvalue of type "uint32_t", else adjust the meaning of "object" such that > u.y isn't considered an object while it's not the active member, or adjust > the meaning of "access the stored value" to suggest that "u.x = 1;" doesn't > access the stored value of the aforementioned u.y object. > > Were it not for N1570 6.3(7), there would be no problem with straightforward > definitions of "object" and "lvalue". As it is, though, I can't see any way > to reconcile straightforward definitions of those terms with the rules as > written in a way that wouldn't make unions completely useless *even in cases > that don't involve aliasing*. In my copy of N1570, 6.3 is about conversions, and there is no 6.3(7), so I'm not sure what you mean by that. Can you please quote the text that you are referring to?