Re: lvalue types

From	Keith Thompson <kst-u@mib.org>
Newsgroups	comp.lang.c
Subject	Re: lvalue types
Date	2018-04-03 11:33 -0700
Organization	None to speak of
Message-ID	<ln8ta4rvh3.fsf@kst-u.example.com> (permalink)
References	(9 earlier) <ln370lwl52.fsf@kst-u.example.com> <kfnd0zllgtf.fsf@x-alumni2.alumni.caltech.edu> <lnmuypttsx.fsf@kst-u.example.com> <lnlge5s13c.fsf@kst-u.example.com> <d36fce32-7231-42f7-a914-9a0411a248bd@googlegroups.com>

Show all headers | View raw

supercat@casperkitty.com writes:

> On Monday, April 2, 2018 at 5:19:48 PM UTC-5, Keith Thompson wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>> [...]
>> > 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".)
>> [...]
>> 
>> 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  <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