Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #128587

Re: lvalue types

Show all headers | View raw

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> 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 <stdio.h>
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  <http://www.ghoti.net/~kst>
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"

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-26 23:44 -0700
  Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-27 09:14 -0700
    Re: lvalue types supercat@casperkitty.com - 2018-03-27 12:21 -0700
      Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-28 17:01 -0700
      Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-29 01:54 -0700
    Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-30 08:32 -0700
      Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-30 09:25 -0700
        Re: lvalue types jameskuyper@verizon.net - 2018-03-30 10:58 -0700
        Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-31 00:52 -0700
        Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-02 15:19 -0700
          Re: lvalue types supercat@casperkitty.com - 2018-04-03 10:06 -0700
            Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-03 11:33 -0700
              Re: lvalue types supercat@casperkitty.com - 2018-04-03 12:19 -0700
                Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-03 12:48 -0700
              Re: lvalue types supercat@casperkitty.com - 2018-04-05 10:17 -0700
                Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-05 10:52 -0700
                Re: lvalue types supercat@casperkitty.com - 2018-04-05 12:39 -0700
                Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-06 06:13 -0700
        Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-04 16:38 -0700
  Re: lvalue types supercat@casperkitty.com - 2018-03-27 12:09 -0700
    Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-28 10:48 -0700

csiph-web