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 11:45:39 -0800 Organization: None to speak of Lines: 88 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="0eef9b872551db80e0dbf35f8b02cad5"; logging-data="7935"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18YQlA4K49r4+CXS+rfGy5E" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:aKKjKoZj5Yl/fzFVHtQccJYJ9ZM= sha1:R5EB70YffuWNyd7Ur+88QOfxbS8= Xref: csiph.com comp.lang.c:127276 supercat@casperkitty.com writes: > On Friday, March 2, 2018 at 11:50:34 AM UTC-6, Keith Thompson wrote: >> I understand that you dislike the effective type rules. Now you're >> using a simple and easily fixable oversight as an excuse to get rid of >> them and invent a new set of rules to replace them. >> >> Not gonna happen. > > What's necessary to make the rules C89 workable without bodges is simply > to recognize that an lvalue that is *visibly derived* from an lvalue of > another type may be used to access an object of that latter type. I > would not blame the authors of C89 for having failed to imagine that > compiler writers might be so willfully blind as to ignore such a > possibility, and would thus not blame them for having failed to explicitly > provide for it. How does compiler writers being "willfully blind" relate to the glitch we're discussing? The problem is that the standard seems not to define the behavior of: struct { int m; } obj; obj.m = 42; What compiler fails to implement that in the obvious manner? [...] >> So you suggest adding a rule that says that given >> int *p; >> the lvalue *p might have a type other than int in some circumstances. >> >> That's insane. > > Essentially, it would require regarding the phrase "lvalue expression" as > a term of art with a meaning beyond "expression which yields an lvalue". You should refresh your memory on what the word "lvalue" actually means before you try to change the definition. An lvalue is a kind of expression. Specifically, it's an expression that (potentially) designates an object. (The word "potentially" was added in C11 to ensure that *ptr is considered an lvalue even if ptr is a null pointer value when the expression is evaluated.) An expression doesn't "yield" an lvalue. An expression may *be* an lvalue. And like any expression, it has a unique and well defined type. > Given "struct S { M m; } s;", s.m would be an "lvalue expression" with > type "struct S", which would yields an lvalue of type "M". The pointer > expression &s.m would yield a pointer to the lvalue expression &s.m, and > an lvalue expression which dereferences that pointer would then yield > the lvalue expression from which it had been derived. Again, this makes no sense unless you're going to radically change the meaning of "lvalue". [...] >> There's at least one similar case that I'm aware of. N1570 6.4.5 >> describes string literals. It goes into great detail about the storage >> duration, type, and contents of the array corresponding to a string >> literal. It never actually says that the value of the string literal is >> the value of that array. Nobody is going to misunderstand the intent. > > String literals are a poor example (see 6.4.5p6), but anyway... They're an example of something obvious that was omitted from the standard. I don't know why you think they're a poor example. The standard describes the array object associated with a string literal. It fails to say that a string literal is an lvalue that designates that object. Nobody has been inconvenienced by this oversight because the intent is so obvious. > I don't think anyone disputes the C89 authors' intention that an lvalue > of a struct or union's member type must be usable *in at least some cases* > to access that struct or union. There is substantial dispute about what > those cases are, and the authors of the Standard cannot plausibly be > unaware of such dispute. Your track record for reading the minds of the committee members is not a good one. -- 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"