Re: lvalue types

From	Keith Thompson <kst-u@mib.org>
Newsgroups	comp.lang.c
Subject	Re: lvalue types
Date	2018-04-03 12:48 -0700
Organization	None to speak of
Message-ID	<lnwoxoqdfe.fsf@kst-u.example.com> (permalink)
References	(11 earlier) <lnmuypttsx.fsf@kst-u.example.com> <lnlge5s13c.fsf@kst-u.example.com> <d36fce32-7231-42f7-a914-9a0411a248bd@googlegroups.com> <ln8ta4rvh3.fsf@kst-u.example.com> <f22455ea-6bf6-4e34-9efc-2f268dacca82@googlegroups.com>

Show all headers | View raw

supercat@casperkitty.com writes:
> On Tuesday, April 3, 2018 at 1:33:27 PM UTC-5, Keith Thompson wrote:
[...]
>> 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).
>
> So if I copy "obj" to s1 before the assignment to *ptr, and I copy it to
> s2 after, then s1 and s2 will end up holding the same values?

No.  Why would you think that?

>> 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.
>
> All that would be necessary would be to say that accesses must "use" an
> lvalue of the proper type, for a reasonable definition of "use".  Note
> that under a literal reading of the Standard, even something like:
>
>     char ch;
>     ch=5;
>
> would invoke Undefined Behavior, because the lvalue ch doesn't modify
> the storage, and the expression that does modify the storage isn't an
> lvalue.

The wording is a bit sloppy.  It says "An object shall have its stored
value accessed only by an lvalue expression that has one of the
following types: [...]", and you're right, objects are not accessed "by"
lvalues.  The only reasonable interpretation is that in your example:
    char ch;
    ch=5;
the "lvalue expression" being referred to is `ch`, the LHS of the
assignment (which has "a type compatible with the effective type of the
object").

I haven't thought about how to reword it to make the intent clearer.

[snip]

To repeat what I've said earlier, it seems obvious to me that
`obj.m = 42` has defined behavior and that it accesses (specifically
modifies) both the object `obj.m` and the object `obj`.  Adding a level
of indirection:
    int *ptr = &obj.m;
    *ptr = 42;
doesn't, or shouldn't, fundamentally change anything.  My reading of
6.5p7 is that the access of the object `obj` violates the effective
type rules as they are currently written.  I believe this to be
an oversight (and effectively a fairly minor one, given that I
expect that every compiler in the real world does the right thing).
Of course doing the "right thing" still conforms to the standard as
it's currently written, since the behavior appears to be undefined.

(At this time, I'm not going to worry too much about aliasing of
distinct members of a struct with the same type.  I'm concentrating
on the simplest case I can think of, modifying a single member of
a single struct object.)

-- 
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