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

Groups > comp.lang.c > #127285

Re: lvalue types

Show all headers | View raw

On Friday, March 2, 2018 at 1:45:52 PM UTC-6, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> > What's necessary to make the rules C89 workable without bodges is simply
> > to recognize that an lvalue that is *visibly derived* from an lvalue of
> > another type may be used to access an object of that latter type.  I
> > would not blame the authors of C89 for having failed to imagine that
> > compiler writers might be so willfully blind as to ignore such a
> > possibility, and would thus not blame them for having failed to explicitly
> > provide for it.
> 
> How does compiler writers being "willfully blind" relate to the glitch
> we're discussing?

Given something like:

    union U { int i; float f; };
    int test(union U up[], int x, int y)
    {
      int *ip1 = &up[x].i;
      *ip1 = 1;
      float *fp = &up[y].f;
      *fp = 1.0f;
      int *ip2 = &up[x].i;
      return *ip2;
    }

I would say that any compiler that bothered to look for such things would
be able to process the above in a fashion equivalent to:

    int test(union U up[], int x, int y)
    {
      up[x].i = 1;
      up[y].f = 1.0f;
      return up[x].i;
    }

This wouldn't require doing anything particularly sophisticated.  On a
compiler that caches values and lvalues in registers, it would merely
require that taking the address of a union member flush the cache of any
lvalues of that union type, or lvalues that might have been derived from
that union type *since the function started executing*.  Doing that for
the derivation of ip2 would ensure that up[y].f got written before the
final read of up[x].i.

GCC, however, ignores the completely visible derivations of *fp from up[y]
and *ip2 from up[x].

> The problem is that the standard seems not to define the behavior of:
> 
>     struct { int m; } obj;
>     obj.m = 42;
> 
> What compiler fails to implement that in the obvious manner?

Given

    union { T1 m1; T2 m2; } u;

is the proper behavior of things like:

    T1 *p1 = &u.m1;
    *p1 = valueOfTypeT1;

or

    T2 *p2 = &u.m2;
    *p2 = valueOfTypeT2;

really any less obvious?  If code can't reliably use the address of a
union member even in simple cases like the above, why allow the address
of a union member to be stored into a pointer of the member type?

> > Essentially, it would require regarding the phrase "lvalue expression" as
> > a term of art with a meaning beyond "expression which yields an lvalue".
> 
> You should refresh your memory on what the word "lvalue" actually means
> before you try to change the definition. An lvalue is a kind of
> expression.  Specifically, it's an expression that (potentially)
> designates an object.  (The word "potentially" was added in C11 to
> ensure that *ptr is considered an lvalue even if ptr is a null pointer
> value when the expression is evaluated.)

My point is that 6.5p7 uses the term "lvalue expression" rather than
"lvalue", and seems to be talking about something other than the final
type that would be yielded by processing the whole expression.

> An expression doesn't "yield" an lvalue.  An expression may *be* an
> lvalue.  And like any expression, it has a unique and well defined type.

An expression like someArray[func()].foo cannot identify any particular
object of the element type until it is executed and func() is called.  As
such, its behavior is that of an expression which, when evaluated, yields
something that can uniquely identify an object.  What terminology would
you suggest to distinguish between something that encapsulates the identity
of a particular object, versus an expression that will identify a [possibly
different] object each time it is executed?

> > Given "struct S { M m; } s;", s.m would be an "lvalue expression" with
> > type "struct S", which would yields an lvalue of type "M".  The pointer
> > expression &s.m would yield a pointer to the lvalue expression &s.m, and
> > an lvalue expression which dereferences that pointer would then yield
> > the lvalue expression from which it had been derived.
> 
> Again, this makes no sense unless you're going to radically change the
> meaning of "lvalue".

The Standard sometimes uses words to describe multiple concepts, without
clearly distinguishing which concept is meant in which case.

> > I don't think anyone disputes the C89 authors' intention that an lvalue
> > of a struct or union's member type must be usable *in at least some cases*
> > to access that struct or union.  There is substantial dispute about what
> > those cases are, and the authors of the Standard cannot plausibly be
> > unaware of such dispute.
> 
> Your track record for reading the minds of the committee members is not
> a good one.

The Committee decided in DR#28 that because code which writes one union
member and reads another has Implementation-Defined behavior, a function
that receives pointers to two union members, writes one, and reads the
other has Undefined Behavior.  The logic there totally escapes me.  On
the other hand, unless you think the Committee was asleep while DR#28 was
written and is somehow unaware of its existence, I'd regard DR#28 as
strong evidence that the Committee was aware that people found the Standard
unclear about the relationship between unions and their members.

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