Re: lvalue types

Newsgroups	comp.lang.c
Date	2018-04-05 10:17 -0700
References	(10 earlier) <kfnd0zllgtf.fsf@x-alumni2.alumni.caltech.edu> <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>
Message-ID	<ffcac6dc-aea6-4e10-a340-2ed2ef14ba0e@googlegroups.com> (permalink)
Subject	Re: lvalue types
From	supercat@casperkitty.com

Show all headers | View raw

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?

The stated purpose of the 6.5p7 is to let compilers make assumptions about
what things may or may not be aliased.  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.  Interpreting
it as applying only in cases where reference lifetimes overlap would not
have such an effect.

Given something like:

    struct s1 {int x; ...};

    void useS1(struct s1 * restrict p1) { ... }

    union u { struct s1 v1; ...};

    void test(union u * restrict p2)
    {
       ...
       useS1(&p2->v1);
       ...
    }

a compiler that is only generating code for s1 that needs to be callable
from any context would have no way of knowing whether "p1" might actually
be used to access a "union u", but it would also have no reason to care
since nothing that isn't derived from "p1", whether of type "union u" or
any other type, is going to be used in ways that could alias "*p1" within
the execution of the function.  If the code for "useS1" is being in-lined
in "test", a compiler would have reason to care that p1 might access
something that is also accessed via lvalue of type "union u", but that's
because it generated code to derive p from an lvalue of that type.  The
authors of the Standard may not have forbidden compilers from using the
rules to "prove" that p2 can't actually identify an object of type "union u"
despite the fact that it is a pointer of that type, because that address
is used with an lvalue of type "struct s1", but IMHO that's because they
didn't think any compiler writer would be crazy enough to think that would
be a good idea.

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