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

Groups > comp.lang.c > #127271

Re: lvalue types

Show all headers | View raw

On Friday, March 2, 2018 at 7:06:29 AM UTC-7, Steven Petruzzellis wrote:
> On Friday, March 2, 2018 at 6:04:32 AM UTC-7, Steven Petruzzellis wrote:
> > On Friday, March 2, 2018 at 1:22:36 AM UTC-7, supe...@casperkitty.com wrote:
> > > 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.
> > > 
> > > 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".
> > > 
> > > If one looks at the effects of recognizing derived lvalues compared with
> > > the effects of granting a general permission to access any struct using
> > > any lvalue of a member's type, the former would allow better semantics
> > > with fewer bodges than the latter, and could thus more easily yield
> > > efficient and correct code.
> > > 
> > > > > 4. The assignments invoke UB because of 6.5p7.
> > > > 
> > > > Consistent with an extremely pedantic reading of the standard, but
> > > > clearly not the intent.
> > > 
> > > Should code which tries to use non-character-type members/elements
> > > of structs, unions, or arrays be branded as non-conforming?
> > > 
> > > > Let me make the point more succinctly.
> > > > 
> > > >     struct s { int m; };
> > > >     struct s obj;
> > > >     obj.m = 42;
> > > > 
> > > > obj.m is an lvalue of type int.  The assignment accesses (specifically
> > > > modifies) the object obj.m, which is of type int; that's perfectly fine
> > > > under 6.5p7.  It also accesses (i.e., modifies) the object obj, which
> > > > is of type struct s.  N1570 6.5p7 says that:
> > > > 
> > > >     An object shall have its stored value accessed only by an lvalue
> > > >     expression that has one of the following types:
> > > > 
> > > > followed by 6 bullet points, none of which allow an object of type
> > > > struct s to be accessed by an lvalue of type int.
> > > > 
> > > > 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.
> > > 
> > > Trying to treat blocks of storage as though they have types is a
> > > needlessly over-complicated model compared with focusing on what
> > > compilers actually need to know, which is whether various operations
> > > must be treated as sequenced relative to each other.  Consider the
> > > effects of saying that an access using a derived lvalue may at the
> > > compiler's option be regarded as occurring any time between when the
> > > lvalue is derived and the time the access is requested.  Thus, given
> > > 
> > >     union U {int i; float f;} *up1,*up2;
> > >     ...
> > >     int *ip = &up1.i;
> > >     float *fp = &up2.f;
> > >     *ip = 1;
> > >     *fp = 1.0f;
> > > 
> > > because *fp is derived from &up2.f before the write to *ip, but the
> > > assignment to *fp occurs after, the assignments to *ip and *fp would
> > > be unsequenced.  Had the code instead been:
> > > 
> > >     union U {int i; float f;} *up1,*up2;
> > >     ...
> > >     int *ip = &up1.i;
> > >     *ip = 1;
> > >     float *fp = &up2.f;
> > >     *fp = 1.0f;
> > > 
> > > the fact that the derivation of *fp occurs after the assignment to *ip
> > > would mean that the assignment to *fp would likewise be sequenced
> > > after the assignment to *ip.
> > > 
> > > > I suggest that 6.5p7 should be updated to state that, in addition to the
> > > > 6 bulleted possibilities, a valid access of a subobject is a valid
> > > > access of the containing object.  I don't believe any other changes are
> > > > needed.
> > > 
> > > That ends up leaving some annoying corner cases if applied to structures,
> > > and even worse ones if applied to unions.  As a simple example, given
> > > two pointers p1 and p2 to the same structure type which has members x
> > > and y of int type, can p1->x alias p2->y?  If both lvalues are seen
> > > as being of type "int", they could.  If, however, the two lvalues are
> > > seen as being attached to the structure type but there is sequencing
> > > slop based on when they were derived, then operations which would aloas
> > > p1->x and p2->y would overlap in time as well as space, thus triggering
> > > the rule about overlapping structures.
> > 
> > 
> > 
> > I suspect Adam LeMond does not even know what is wrong with Clinton. It's his problem and he has to want to deal with it. Obviously he would rather blame Vennie Bowden than face reality. The Mac has better screencasting programs. Meanwhile Linux has no tasks it handles better. 
> > 
> > With no evidence at all, as is usual for Adam LeMond. 
> > 
> > --
> > My Snoring Solution
> > https://youtu.be/UkAyrfOZaXc
> > https://youtu.be/qwb1Ez0GWMA
> > http://www.5z8.info/trojan_p4g1zy_how-to-skin-a-gerbil
> > Jonas Eklundh Communication AB
> 
> 
> 
> All that Tatiana Spearman Kister cares about is that Tatiana Spearman Kister gets to broadcast his spam message and then hang up and giggle about it. The fact that Paul F. Riddle is a real person on the other end of the phone is what gets him off. Regardless of my own avoidance of Debian, I even now continue to load it for users who have had complications with macOS. Now that Paul F. Riddle realized how successful Tatiana Spearman Kister is at portraying himself as the 'injured party' he realizes this is not as insane as it was claimed. 
> 
> In fact Tatiana Spearman Kister's lies got bigger. So as might be expected I regret sending hardware to Tatiana Spearman Kister. While I am sure he appreciated it, I've not helped the situation at all. What did Paul F. Riddle assume from the lying imbecile? That Tatiana Spearman Kister bozo has nothing to blow but time. He has nothing else. Especially not ambition. 
> 
> --
> This Trick Gets Women Hot For You!!
> https://youtu.be/UkAyrfOZaXc
> https://youtu.be/5OfWsoPAg7o
> https://youtu.be/E3m_i-x92D0
> Jonas Eklundh Communication



He is as incompetent as Robert Wessel. 

How is barely used potential gray matter tied to flatlining brain waves in any way going to lead to improved newsgroup writing? 

Robert Wessel must realize that Jonathan Rhodes can go get FileMaker, right, gluey? Meanwhile, anyone can can set a KF, which renders _his_ immature nonsense meaningless, just like Robert Wessel ;) 



--
What Every Entrepreneur Must Know
http://www.5z8.info/freeanimalporn.com-start-download_s9j7do_dogporn
Jonas Eklundh

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