Re: lvalue types

From	Keith Thompson <kst-u@mib.org>
Newsgroups	comp.lang.c
Subject	Re: lvalue types
Date	2018-03-02 11:45 -0800
Organization	None to speak of
Message-ID	<lnvaeefeho.fsf@kst-u.example.com> (permalink)
References	<2b687d74-f559-43a9-9aec-8a1067467ce2@googlegroups.com> <ln4llzgsus.fsf@kst-u.example.com> <b718a3f5-ca92-479f-bc93-d4a5a2e116ce@googlegroups.com> <lnzi3qfju0.fsf@kst-u.example.com> <dbac55d2-bcc8-4ce1-915b-5cfa78257159@googlegroups.com>

Show all headers | View raw

supercat@casperkitty.com writes:
> On Friday, March 2, 2018 at 11:50:34 AM UTC-6, Keith Thompson wrote:
>> 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.
>
> 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?

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?

[...]

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

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.

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

[...]

>> 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.
>
> String literals are a poor example (see 6.4.5p6), but anyway...

They're an example of something obvious that was omitted from the
standard.  I don't know why you think they're a poor example.

The standard describes the array object associated with a string
literal.  It fails to say that a string literal is an lvalue that
designates that object.  Nobody has been inconvenienced by this
oversight because the intent is so obvious.

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

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