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

Groups > comp.lang.c > #127241

Re: lvalue types

Show all headers | View raw

On Thursday, March 1, 2018 at 7:37:59 PM UTC-6, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> > 2. An object of aggregate type can be modified using an lvalue of member
> >    type, at least in these particular cases, even though that's not one
> >    of the possibilities listed in 6.5p7.
> 
> Yes, due to an apparent oversight in the standard.

There is clearly a problem somewhere in the Standard, but if the lack
of another bullet point were a simple oversight it would have been fixed
in C99 or, at the very least, C11.  Adding an extra bullet point might be
somewhat workable for structures, though it would disallow some useful
optimizations, but applying it to union types would just muddle things
even worse than they already are.

What's needed instead is to get rid of all the bodges that try to
allow for objects to receive "effective types" or to be accessed with
"character type" pointers, and instead recognize that deriving a
pointer from an lvalue or portion thereof is an important sequenced
action which, at least temporarily, associates that pointer with that
object--an association that could benefit programmers and compiler
writers alike.

If such an association is recognized, that would resolve even the case
of taking the address of a union member.  Given:

    union { int i; float f; } *up1;
    int *fp = &up1->f; *fp = 1;

treating operations on *fp as operations on *up1 would mean that the
assignment to *fp used an lvalue associated with something of a union
type to access objects with types "int" and "float"--a usage which
is explicitly allowed under 6.5p7 since both "int" and "float" are
members of *the union being accessed*.

> > 3. For purposes of 6.5p7 the left-side operand is an lvalue of type
> >    "struct S", even though for purposes of 6.5.3.2 the the type of
> >    the lvalues in each case would seem to be "int", or...
> 
> Absurd.  The standard is crystal clear that each of the lvalues in
> question is of type int.

The Standard is also crystal clear that using an lvalue of type "int"
to access storage associated with a structure type is not allowed even
if that structure happens to contain a member of type "int".

If one looks at the effects of recognizing derived lvalues compared with
the effects of granting a general permission to access any struct using
any lvalue of a member's type, the former would allow better semantics
with fewer bodges than the latter, and could thus more easily yield
efficient and correct code.

> > 4. The assignments invoke UB because of 6.5p7.
> 
> Consistent with an extremely pedantic reading of the standard, but
> clearly not the intent.

Should code which tries to use non-character-type members/elements
of structs, unions, or arrays be branded as non-conforming?

> Let me make the point more succinctly.
> 
>     struct s { int m; };
>     struct s obj;
>     obj.m = 42;
> 
> obj.m is an lvalue of type int.  The assignment accesses (specifically
> modifies) the object obj.m, which is of type int; that's perfectly fine
> under 6.5p7.  It also accesses (i.e., modifies) the object obj, which
> is of type struct s.  N1570 6.5p7 says that:
> 
>     An object shall have its stored value accessed only by an lvalue
>     expression that has one of the following types:
> 
> followed by 6 bullet points, none of which allow an object of type
> struct s to be accessed by an lvalue of type int.
> 
> It's obvious that the assignment is meant to be well defined.  I'd say
> this is a simple oversight in the wording of the standard (unless
> someone can come up with another interpretation).  I don't know whether
> anyone else has noticed this before.  If you're the first,
> congratulations.

If it was a simple oversight, why hasn't it been fixed in the decades
between C89 and C11?  I doubt there was ever any shared understanding
about what C89 was supposed to mean.  Even though the present wording
is terrible, nobody is willing to accept any alternative wording that
would disagree with their interpretation of what the old wording means.

Trying to treat blocks of storage as though they have types is a
needlessly over-complicated model compared with focusing on what
compilers actually need to know, which is whether various operations
must be treated as sequenced relative to each other.  Consider the
effects of saying that an access using a derived lvalue may at the
compiler's option be regarded as occurring any time between when the
lvalue is derived and the time the access is requested.  Thus, given

    union U {int i; float f;} *up1,*up2;
    ...
    int *ip = &up1.i;
    float *fp = &up2.f;
    *ip = 1;
    *fp = 1.0f;

because *fp is derived from &up2.f before the write to *ip, but the
assignment to *fp occurs after, the assignments to *ip and *fp would
be unsequenced.  Had the code instead been:

    union U {int i; float f;} *up1,*up2;
    ...
    int *ip = &up1.i;
    *ip = 1;
    float *fp = &up2.f;
    *fp = 1.0f;

the fact that the derivation of *fp occurs after the assignment to *ip
would mean that the assignment to *fp would likewise be sequenced
after the assignment to *ip.

> I suggest that 6.5p7 should be updated to state that, in addition to the
> 6 bulleted possibilities, a valid access of a subobject is a valid
> access of the containing object.  I don't believe any other changes are
> needed.

That ends up leaving some annoying corner cases if applied to structures,
and even worse ones if applied to unions.  As a simple example, given
two pointers p1 and p2 to the same structure type which has members x
and y of int type, can p1->x alias p2->y?  If both lvalues are seen
as being of type "int", they could.  If, however, the two lvalues are
seen as being attached to the structure type but there is sequencing
slop based on when they were derived, then operations which would aloas
p1->x and p2->y would overlap in time as well as space, thus triggering
the rule about overlapping structures.

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

Thread

lvalue types supercat@casperkitty.com - 2018-03-01 16:38 -0800
  Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 17:17 -0800
  Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-01 17:37 -0800
    Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 22:00 -0800
    Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 23:49 -0800
      Re: lvalue types asetofsymbols@gmail.com - 2018-03-05 06:56 -0800
    Re: lvalue types supercat@casperkitty.com - 2018-03-02 00:22 -0800
      Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 01:23 -0800
      Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 05:04 -0800
        Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 06:06 -0800
          Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 08:12 -0800
      Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-02 09:50 -0800
        Re: lvalue types supercat@casperkitty.com - 2018-03-02 11:33 -0800
          Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-02 11:45 -0800
            Re: lvalue types supercat@casperkitty.com - 2018-03-02 16:28 -0800
              Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-02 16:54 -0800
                Re: lvalue types supercat@casperkitty.com - 2018-03-02 17:50 -0800
                Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-02 19:43 -0800
                Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-02 22:51 -0800
                Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 23:07 -0800
                Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 01:44 -0800
                Re: lvalue types supercat@casperkitty.com - 2018-03-03 13:01 -0800
          Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 22:21 -0800
    Re: lvalue types supercat@casperkitty.com - 2018-03-02 09:24 -0800
    Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-03 00:58 -0800
      Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 01:13 -0800
      Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-03 13:01 -0800
        Re: lvalue types supercat <flatfinger@casperkitty.com> - 2018-03-03 17:43 -0800
        Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-04 02:22 -0800
          Re: lvalue types supercat@casperkitty.com - 2018-03-04 13:03 -0800
          Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-04 13:03 -0800
            Re: lvalue types bartc <bc@freeuk.com> - 2018-03-04 22:32 +0000
            Re: lvalue types supercat@casperkitty.com - 2018-03-05 09:45 -0800
      Re: lvalue types supercat@casperkitty.com - 2018-03-03 14:19 -0800
  Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 18:03 -0800

csiph-web