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: Wed, 18 Jan 2017 18:08:59 -0800 Organization: None to speak of Lines: 51 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="42f71f414aecc03fc21842aabbc98242"; logging-data="15234"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Z+fKVMC56aC0yxCJqlK5n" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:4RXFiZomCmyonXZzIHoXXsoGvCM= sha1:TpCtLCiHvrOG9vBEmP8VJOSko4Y= Xref: csiph.com comp.lang.c:102170 supercat@casperkitty.com writes: > On Wednesday, January 18, 2017 at 4:39:58 PM UTC-6, Keith Thompson wrote: >> But structure and union definitions *do* create multiple overlapping >> objects. Introducing this idea of a "view" is neither necessary nor >> helpful. > > The C Standard doesn't really cope well with the existence of multiple > overlapping objects. Sure it does, at least for the purposes of what we're discussing at the moment. Given: struct { uint32_t x, y; } s1; s1, s1.x, and s1.y are all objects. Again, if you disagree, consult the standard's definition of the word "object" and explain how it doesn't apply to all three of them. And if s1.x isn't an object, that's going to break a lot of the existing wording in the standard. > It is helpful to have a concept to describe a region > of storage with a well-defined lifetime which is disjoint from all other > such regions. In other words, an object that's not part of another object. Perhaps it would be helpful in some contexts -- but the Standard copes perfectly well, as far as I can tell, without a specific term for that concept. If you want a term for it, I suppose "full object" would do, by analogy with the existing terms "full expression" and "full declarator". > It is also useful to have a concept to describe a view of > a region of storage whose lifetime may be shorter than that of the storage > thus described, and which can only overlap other "live" views in limited > circumstances. Using the same term to describe both concepts, however, > seems less helpful. > > Given struct s { uint32_t x,y;} *p1,*p2; in what cases, if any, would a > compiler be allowed to assume that p1->x and p2->y cannot alias? In this context, I don't care. The question of whether a given expression is an lvalue or not isn't about aliasing. I see no point in bringing in irrelevant complications. [...] -- 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"