Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: lvalue types Date: Thu, 05 Apr 2018 10:52:34 -0700 Organization: None to speak of Lines: 55 Message-ID: References: <2b687d74-f559-43a9-9aec-8a1067467ce2@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="7bf2a82357868b78051038e61a1f9d6f"; logging-data="22491"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/C2olIdSJnUvKmKP0LsUIq" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:3hMZfeJPhA7Gdb89sfZIYMFTdOs= sha1:smeb2LHQYYRYrxYEbJ0ayLwedfE= Xref: csiph.com comp.lang.c:128791 supercat@casperkitty.com writes: > On Tuesday, April 3, 2018 at 1:33:27 PM UTC-5, Keith Thompson wrote: >> I don't believe that the effective type rules in 6.5p7 are intended to >> include the type of an lvalue that does not appear in the expression >> that actually accesses the object. That would IMHO be a very strained >> reading of what the standard actually says. > > If the applying the address-of operator to a struct or union member does > not yield a pointer that can be dereferenced to access the parent object, > what exactly is its purpose? When did I say that that's not its purpose? Given: struct s { int m; }; struct s obj = { 0 }; int *ptr = &obj.m; *ptr = 42; *of course* the assignment modifies the value of obj.m. My complaint is that the current wording of the effective type rules does not cover this case, assuming that the assignment modifies/access obj as well as obj.m. (Tim has posted another followup on that subject, which I'll reply to Real Soon Now.) > The stated purpose of the 6.5p7 is to let compilers make assumptions about > what things may or may not be aliased. That purpose is stated in a footnote, which is non-normative. Knowing the purpose behind a set of rules is interesting, and it can help resolve ambiguities, but it doesn't alter the rules themselves as they are written. > Interpreting the rule as applying > even in contexts where storage has one clearly-identifiable active reference > at all times would make structs and unions essentially useless. Which is exactly why I advocate fixing the wording. > Interpreting > it as applying only in cases where reference lifetimes overlap would not > have such an effect. I'm not sure what "reference lifetimes overlap" means, but I think you're stretching the wording beyond its breaking point. 6.5p7 says "An object shall have its stored value accessed only by an lvalue expression that has one of the following types: ...". It says nothing about "reference lifetimes". [...] -- 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"