Re: lvalue types

Newsgroups	comp.lang.c
Date	2018-03-05 09:45 -0800
References	(1 earlier) <ln4llzgsus.fsf@kst-u.example.com> <kfn7eqtsfgk.fsf@x-alumni2.alumni.caltech.edu> <lnefl0g9gs.fsf@kst-u.example.com> <kfnh8pwqgwn.fsf@x-alumni2.alumni.caltech.edu> <lna7vnft8l.fsf@kst-u.example.com>
Message-ID	<c83e5df9-d794-4dfd-a6c5-e56dc1528c6d@googlegroups.com> (permalink)
Subject	Re: lvalue types
From	supercat@casperkitty.com

Show all headers | View raw

On Sunday, March 4, 2018 at 3:21:20 PM UTC-6, Keith Thompson wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
> > I would say no.  It does change some, or in this particular case
> > maybe all, of the bytes that hold the object representation of
> > obj, but that's not the same thing.
> 
> I truly do not understand what you're saying here.
> 
> Consider this program:
> 
> #include <stdio.h>
> int main(void) {
>     struct s { int m; };
>     struct s obj = { 0 };
>     printf("obj.m = %d\n", obj.m);
>     obj.m = 42;
>     printf("obj.m = %d\n", obj.m);
> }
> 
> The output is:
> 
> obj.m = 0
> obj.m = 42
> 
> Assume, for simplicity, that struct s has no padding bytes
> (sizeof (struct s) == sizeof (int)) and int has no padding bits
> (the latter probably doesn't matter).
> 
> Before the assignment, obj has one value.  After the assignment, obj
> has a different value.  The value changed because of the assignment.
> 
> To "access" is, by definition, "to read or modify the value of an
> object".
> 
> And you're saying that that assignment, which caused the value of obj to
> change, did not modify the value of obj?
> 
> Are you using a different meaning than I am for some seemingly
> straighforward word?  (value?  object?  modify?)

Applying all of the the normal definitions of terms in the Standard to
6.5p7 would mean that any access to a struct or union member of a non-
character type would never have defined behavior.  On the other hand,
I think most people would agree that there are at least some circumstances
where all usable-quality implementations should be expected to process
such accesses predictably, even though the Standard, as written, has never
required them to do so.

Something's gotta give.  Unfortunately, there is no agreement as to what,
and the language has diverged into a number of incompatible dialects based
upon what one assumes the Standard was intended to say.  Further, the
Committee has refused for 20+ years to do anything that might be perceived
as branding any particular interpretation as "incorrect".

Tim's interpretation is consistent with one I've seen before, and have
sometimes held myself.  Like nearly all such interpretations, it's not
really justifiable based upon anything in the Standard, but since *no*
useful interpretation would be justifiable that shouldn't really be
viewed as a defect.  A bigger problem with that interpretation is its
lack of precision as to what programmers and implementations are allowed
to do.  That too is a problem shared with many interpretations.

IMHO, the best interpretation as I've said repeatedly is to regard the
footnote as saying that 6.5p7 does not apply in cases that do not
involve aliasing.  While that would require further definitions to
clarify what exactly would be considered "aliasing", it would not require
ignoring or "re-interpreting" other parts of the Standard.  That does
not, however, make Tim's interpretation particularly unreasonable.

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