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, 30 Mar 2018 09:25:02 -0700 Organization: None to speak of Lines: 197 Message-ID: References: <2b687d74-f559-43a9-9aec-8a1067467ce2@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: h2725194.stratoserver.net; posting-host="287c9fc6555f97a9d0df4975b865de04"; logging-data="16839"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18N+D7e0a5g9CRu2dCHkJFl" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:4/A3YHTTpXNpVW69/mPlEGYkdW4= sha1:v0+H5Z8XNdy7xVt6rdFcZcdEi3w= Xref: csiph.com comp.lang.c:128587 Tim Rentsch writes: > Keith Thompson writes: >> Tim Rentsch writes: >>> Keith Thompson writes: [...] >>> This model is different from mine. My model is that words in the >>> Standard often mean different things in different places, and we >>> shouldn't assume that a meaning that looks sensible in one place >>> will necessarily be sensible in another place, especially if doing >>> so leads to a paradox of some sort. The idea of falling back on >>> common sense is not really compatible with the multiple-meanings >>> perspective. >> >> Your model leads to no actual conclusions. You don't depend on the >> meanings of English words or on common sense to determine what the >> Standard means. You have reached a specific conclusion (that obj.m >> = 42 doesn't access obj), but nothing in what you've said in this >> thread helps me understand how or why you reached that conclusion >> rather than the opposite one (that obj.m = 42 does access obj). > > If you don't understand my model, how can you claim it leads to no > actual conclusions, especially when you give an example of such a > conclusion yourself? OK, perhaps there's something in your model that leads to the conclusions you say it does. I don't just see how. >>>> Given: >>>> >>>> struct s { int m; }; >>>> struct s obj = { 0 }; >>>> obj.m = 42; >>>> >>>> (I've added an initializer to guarantee that the value actually >>>> changes), I cannot think of any interpretation of the wording or intent >>>> of the standard, precise or imprecise, that would lead to the conclusion >>>> that the assignment modifies obj.m but does not modify obj. >>>> >>>> obj.m has a value before the assignment. It has a different value >>>> after the assignment. obj has a value before the assignment. >>>> It has a different value after the assignment. >>>> >>>> If you're saying that the assignment does not modify the value of obj, >>>> how did you reach that conclusion? If you're saying that the standard >>>> doesn't say whether the assignment modifies the value of obj or not, how >>>> did you reach that conclusion? >>>> >>>> I don't think you mean to say that the standard is imprecise, therefore >>>> you can reach any conclusion you like. >>>> >>>> The definition of "access" is "to read or modify the value of an >>>> object". We can nitpick the imprecise ways the Standard uses the terms >>>> "value" and "object", but I don't see that that leads us anywhere >>>> useful. >>> >>> My model for how to reason here is simply different from yours. >> >> You've told me at length what your model isn't. You haven't told me >> what it is. > > I haven't given a complete description, but I have given some > positive statements (ie, about what it is). Giving a full > description is hard because a lot of it happens in ways that I am > not fully aware of, just as it does for other people. To be able > to describe it requires some serious introspection, and I haven't > had time to do that. Even though I can't give a full description, > here are some affirmative statements that may help: > > (1) A given word (or phrase) sometimes means different things at > different places, depending on context. Sure. > (2) Definitions given in the Standard are not always symmetric. > To give a specific example, if an object is accessed then it is > either inspected or written (or perhaps both), but if a memory > location is inspected or written that does not imply that any > object whose memory region overlaps that memory location is > necessarily accessed. The definition goes one way but not the > other. And I have no idea how you've reached that conclusion. It seems obvious to me, from the meanings of ordinary English words such as "modify", that `obj.m = 42` modifies the vallue of the object obj. obj had one value before the assignment was evaluated, and a different value after it was evaluated. What does "modify" mean if it doesn't apply when the value of an object is changed? I'm not unwilling to try to understand your model, but I have so far been unable to do so. I simply don't see how it makes sense. >>> don't think "this byte of memory was changed, therefore an object >>> that contains that byte of memory must have been accessed." >>> Suppose a byte is changed by being zapped by a cosmic ray, or >>> maybe as a side effect of a volatile access. There is no lvalue >>> expression involved, so under effective type rules both of those >>> are undefined behavior. >> >> This is irrelevant. There is no undefined behavior and no influence >> outside the defined execution of the program in my example. (Unless >> you're claiming that `obj.m = 42` has undefined behavior, but I don't >> think you're saying that.) > > I gave an example that, as I understand your reasoning process, > leads to a paradoxical conclusion. How is that not relevant if > what I am trying to do is better understand your reasoning process > (which is partly what I am trying to do)? Memory being changed by cosmic rays is outside the scope of behavior defined by the standard. Assign a value to a member of a structure is not. The only possible "paradoxical" conclusion is that the effective type rules do not seem to cover the case of assigning a value to a struct member. This is the oversight I've been talking about all along. I don't see it as a paradox, just an error in the standard. [...] > What I'm trying to give is an explanation, not an argument. You > are (probably unconsciously) wedded to a particular worldview. I > have a different worldview, and I am trying to convey that. I'm > not asking you to agree with it, just try to understand it. Is > that so unreasonable? You have conveyed to me that you have a different worldview. You have not conveyed to me (or, if you prefer, I have failed to understand) what that worldview is. [...] >> My conclusions: >> >> obj.m = 42 access both obj.m and obj. obj is an object of type struct >> s. obj.m is an lvalue of type int. The effective type rules do not >> permit (more precisely, do not define the behavior of) modify an object >> of type struct s by an lvalue of type int. This is an oversight in the >> standard. The intent is clear, but the wording needs to be updated to >> cover this case (and probably other cases as well). >> >> You clearly disagree, but I've now given up on coaxing you to explain >> how and why. > > To understand my comments, I think you will have to accept (at least > provisionally) operating in a different worldview. You seem unable > or unwilling to do that. I don't mean to imply anything negative by > that comment, just to make an observation that may help explain why > we have gotten to the place we currently are. I am unable to get a consistent model of your worldview. The simplest way I can think of to explain this is that a worldview in which `obj.m = 42` does not modify the value of obj either is internally inconsistent, or uses the word "modify" in some odd and unexplained sense that is incompatible with either the normal English meaning of the word "modify" or any technical definition I've encountered, or I'm missing something. [...] Let me ask two direct yes/no questions. I think I know what your answers will be, but I'd like to get your answers explicitly. 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".) If your answers are "yes" and "no", respectively, then that's the clearest statement I can think of that your worldview is one that I do not understand. If you think you can explain what the word "modify" means, preferably in a manner that would clarify your answers to these two questions, feel free to do so. Again, obj has a value before the assignment, it has a different value after the assignment, and you say the assignment did not modify obj. -- 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"