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: Tue, 03 Apr 2018 11:33:12 -0700 Organization: None to speak of Lines: 86 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="44da38e7affa7c709ac80b82b9bf6f42"; logging-data="5389"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18+YQsH5KgawnRGF7/NxkIF" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:U9hOGg7ginfxkR9j1SQz2Sv88YQ= sha1:t/5PxbOJR5amQ6isRArN71++sUA= Xref: csiph.com comp.lang.c:128666 supercat@casperkitty.com writes: > On Monday, April 2, 2018 at 5:19:48 PM UTC-5, Keith Thompson wrote: >> Keith Thompson writes: >> [...] >> > Given this program: >> > >> > #include >> > int main(void) { >> > struct s { int m; }; >> > struct s obj = { 0 }; >> > obj.m = 42; >> > printf("%d\n", obj.m); >> > } >> > >> > Does the assignment `obj.m = 42;` modify the value of the object `obj.m`? >> > Does the assignment `obj.m = 42;` modify the value of the object `obj`? >> > (The phrase "modify the value of [the] object" is from the standard's >> > definition of "access".) >> [...] >> >> I thought for a while that there might be something that would resolve >> the oversight I saw in 6.5p7. >> >> In the assignment expression >> >> obj.m = 42 >> >> there are two lvalues, `obj` and `obj.m`. One could argue that obj is >> accessed by the value `obj`, which is of type `struct s`. >> >> But on further thought, that doesn't resolve it: >> >> struct s { int m; }; >> struct s obj = { 0 }; >> int *ptr = &obj.m; >> *ptr = 42; >> >> In this assignment, there is no lvalue of type `struct s`, but the >> object `obj` of type `struct s` is modified. >> >> Oh well. >> >> (I remain convinced that both obj.m and obj are accessed/modified >> by the assignment.) > > They are, but the assignment to *ptr involves the lvalue "obj" in a way > which would be visible to any compiler that makes any effort to see it. Compilers are not required to make that effort, but that's not relevant anyway. Even if `*ptr = 42` involves an lvalue of type `struct s`, it doesn't matter whether the compiler is able to determine that it does. The effective type rules describe which accesses do or do not have defined behavior. If we were to argue that `*ptr = 42` involves an lvalue of type `struct s`, that argument would be based on the lvalue(s) in the expression being "derived" from an lvalue of type `struct s`, not on whether the compiler knows that. > The address-of operator would be rather silly if it didn't allow a derived > lvalue to be used to access storage within the parent at least in cases > where it is the most recently derived lvalue that will be used to access > the storage in question, and a non-blind compiler can see its derivation. In the assignment `*ptr = 42`, the value of obj is not modified "by" the lvalue `obj` that appears on a previous line. The only lvalues in that assignment are `ptr` (which undergoes lvalue conversion, yielding a value of type int*) and `*ptr` (which is used to access obj.m). 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. > The $64,000 question is whether P6.5p7 is meant to be interpreted as saying > that lvalues used for access must be visibly derived from lvalues of the > proper type, or as saying that the visible derivation of a pointer to a > union member may be ignored if some other member was last used to access the > union. -- 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"