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: Fri, 02 Mar 2018 19:43:08 -0800 Organization: None to speak of Lines: 63 Message-ID: References: <2b687d74-f559-43a9-9aec-8a1067467ce2@googlegroups.com> <75924da9-ff5c-4cb1-a84b-93c93970bd11@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="bc1147ccc842b73bdba534adacdee29b"; logging-data="20254"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19HLKnOWSjdw8g+w5/GCM+d" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:UNvuFCx7R+CxfzPW1vZZ39KGBLE= sha1:1kOfOeORZPMznrszl3nXlnFHhSE= Xref: csiph.com comp.lang.c:127290 supercat@casperkitty.com writes: > On Friday, March 2, 2018 at 6:54:30 PM UTC-6, Keith Thompson wrote: >> The phrase "lvalue expression" is redundant; the word "expression" could >> (and probably should) have been omitted. It simply means "an expression >> that is an lvalue". I can think of no other plausible meaning, since >> there is exactly zero doubt that an lvalue is a kind of expression. >> When it talks about the type of the "lvalue expression", it simply means >> the type of the expression (which is an lvalue). I see no ambiguity, >> only a missing bullet point about accessing subobjects. > > As I've said before, adding a bullet point wouldn't work. The 6.5p7 rules > describe the situations in which compilers must allow for the possibility > of lvalues *which have no visible relationship between them*. The 6.5p7 rules specify the lvalues that can be used to access an object. It's not just about lvalues that have "no visible relationship". Given: int n; n = 42; the access is valid because of the first bullet point; the lvalue `n` has "a type compatible with the effective type of the object". BTW, do you agree that an lvalue is a kind of expression, and that the phrase "lvalue expression" has no intended meaning other than "lvalue" or "expression that is an lvalue"? > Does the Standard recognize the concept of "expressions" that don't appear > in the preprocessed source text? I don't think so. Why would it? > Following the execution of: > > struct bar { int x;}; > struct foo { int q; struct bar y;}; > struct foo *test9(void) > { > int x=0; > struct foo *p = malloc(2*sizeof (struct foo)); > struct bar *p2 = &(p[++x].y); > return p; > } > > What term would you use for the things whose address was assigned to p2? > It can't be an "object" of type p2 because at that point in the code no You mean of type struct bar. > such object has ever been created. Expressions in source text don't have > addresses. So what is that thing? The malloc call "allocates space for an object", so I'd call it an object. Since that object is not accessed, I suppose it doesn't have an effective type. If later code were to evaluate *p2, that would impose an effective type of struct bar on that object, if I understand 6.5p6 correctly. (I haven't given this a whole lot of thought, so I could be missing something.) -- 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"