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

Groups > comp.lang.c > #127273

Re: lvalue types

Show all headers | View raw

supercat@casperkitty.com writes:
> 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.

I understand that you dislike the effective type rules.  Now you're
using a simple and easily fixable oversight as an excuse to get rid of
them and invent a new set of rules to replace them.

Not gonna happen.

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

As I said, that appears to be a simple oversight, one that wasn't
noticed because the intent (that member selection is intended to work)
is so obvious.  (Or I've missed something, which is always a
possibility.)

So you suggest adding a rule that says that given
    int *p;
the lvalue *p might have a type other than int in some circumstances.

That's insane.

[...]

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

I don't know why it wasn't fixed, but my guess is that nobody noticed
because the intent is so obvious, and the oversight has never affected
either compiler writers or programmers.

There's at least one similar case that I'm aware of.  N1570 6.4.5
describes string literals.  It goes into great detail about the storage
duration, type, and contents of the array corresponding to a string
literal.  It never actually says that the value of the string literal is
the value of that array.  Nobody is going to misunderstand the intent.

[...]

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

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