Re: lvalue types

From	Keith Thompson <kst-u@mib.org>
Newsgroups	comp.lang.c
Subject	Re: lvalue types
Date	2018-04-05 10:52 -0700
Organization	None to speak of
Message-ID	<lnh8opr15p.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> <ffcac6dc-aea6-4e10-a340-2ed2ef14ba0e@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:
>> 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.
>
> If the applying the address-of operator to a struct or union member does
> not yield a pointer that can be dereferenced to access the parent object,
> what exactly is its purpose?

When did I say that that's not its purpose?  Given:

    struct s { int m; };
    struct s obj = { 0 };
    int *ptr = &obj.m;
    *ptr = 42;

*of course* the assignment modifies the value of obj.m.  My complaint
is that the current wording of the effective type rules does not
cover this case, assuming that the assignment modifies/access obj
as well as obj.m.  (Tim has posted another followup on that subject,
which I'll reply to Real Soon Now.)

> The stated purpose of the 6.5p7 is to let compilers make assumptions about
> what things may or may not be aliased.

That purpose is stated in a footnote, which is non-normative.  Knowing
the purpose behind a set of rules is interesting, and it can help
resolve ambiguities, but it doesn't alter the rules themselves as they
are written.

>                                         Interpreting the rule as applying
> even in contexts where storage has one clearly-identifiable active reference
> at all times would make structs and unions essentially useless.

Which is exactly why I advocate fixing the wording.

>                                                                  Interpreting
> it as applying only in cases where reference lifetimes overlap would not
> have such an effect.

I'm not sure what "reference lifetimes overlap" means, but I
think you're stretching the wording beyond its breaking point.
6.5p7 says "An object shall have its stored value accessed only
by an lvalue expression that has one of the following types: ...".
It says nothing about "reference lifetimes".

[...]

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