Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #127213 > unrolled thread
| Started by | supercat@casperkitty.com |
|---|---|
| First post | 2018-03-01 16:38 -0800 |
| Last post | 2018-03-26 23:04 -0700 |
| Articles | 9 on this page of 149 — 11 participants |
Back to article view | Back to comp.lang.c
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 Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-19 09:54 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-19 11:52 -0700
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
Re: lvalue types supercat@casperkitty.com - 2018-03-19 12:27 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-03 14:02 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-04 17:32 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-04 20:24 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-09 08:31 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-11 11:19 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-11 12:44 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-12 06:45 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-12 07:54 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-12 14:26 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-12 14:43 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-12 17:40 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-13 03:02 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-13 00:27 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-13 07:19 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-16 08:52 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-16 10:28 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-16 13:58 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-16 14:52 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-16 16:22 -0700
Re: lvalue types Richard Damon <Richard@Damon-Family.org> - 2018-04-16 21:51 -0400
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-16 19:42 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-16 21:30 -0700
Re: lvalue types Richard Damon <Richard@Damon-Family.org> - 2018-04-17 07:01 -0400
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-17 04:22 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-19 02:43 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 07:25 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-17 08:48 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 09:54 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-17 10:37 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 11:00 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-17 11:48 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 12:45 -0700
Re: lvalue types scott@slp53.sl.home (Scott Lurndal) - 2018-04-17 19:55 +0000
Re: lvalue types jameskuyper@verizon.net - 2018-04-17 13:13 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 14:00 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-17 19:45 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 08:27 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-18 09:12 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 10:13 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-18 11:01 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 11:51 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 12:15 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 12:30 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 13:25 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-19 10:51 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-18 12:38 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 14:39 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 21:17 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-19 02:40 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-19 03:01 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-19 06:49 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-19 07:58 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-20 08:19 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-19 12:17 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-19 12:51 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-19 13:37 -0700
Re: lvalue types scott@slp53.sl.home (Scott Lurndal) - 2018-04-19 21:08 +0000
Re: lvalue types supercat@casperkitty.com - 2018-04-19 14:50 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-19 14:56 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-19 16:13 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-21 10:27 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-23 11:37 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-18 16:07 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 09:20 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 11:25 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-04-17 14:13 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-17 15:05 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-17 19:57 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 08:43 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 09:36 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-17 11:37 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-17 20:23 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 09:23 -0700
Re: lvalue types scott@slp53.sl.home (Scott Lurndal) - 2018-04-18 17:29 +0000
Re: lvalue types supercat@casperkitty.com - 2018-04-18 10:47 -0700
Re: lvalue types bartc <bc@freeuk.com> - 2018-04-18 20:04 +0100
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 10:48 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 13:23 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-18 14:26 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-18 15:36 -0700
Re: lvalue types jameskuyper@verizon.net - 2018-04-19 10:39 -0700
Re: lvalue types supercat@casperkitty.com - 2018-04-19 12:42 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-16 21:29 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-23 11:39 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-04 21:30 -0700
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
Re: lvalue types John Bode <jfbode1029@gmail.com> - 2018-03-21 10:33 -0700
Re: lvalue types Keith Thompson <kst-u@mib.org> - 2018-03-21 11:53 -0700
Re: lvalue types Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-22 00:11 -0700
Re: lvalue types supercat@casperkitty.com - 2018-03-21 11:53 -0700
Re: lvalue types Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-26 23:04 -0700
Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-04-23 11:39 -0700 |
| Message-ID | <kfny3hd3gz7.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #129101 |
I am more or less ready with a response here but I am waiting for Keith's followup so I don't interfere with what he has to say.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-04 21:30 -0700 |
| Message-ID | <e688160a-992d-4a09-8b1a-aa3e4f3d3936@googlegroups.com> |
| In reply to | #128739 |
On Wednesday, April 4, 2018 at 5:32:41 PM UTC-7, Tim Rentsch wrote:
> jameskuyper@verizon.net writes:
>
> > On Sunday, March 4, 2018 at 5:22:47 AM UTC-5, Tim Rentsch wrote:
> >
> >> Keith Thompson <kst-u@mib.org> writes:
> >>
> >>> Tim Rentsch <txr@alumni.caltech.edu> writes:
> >>>
> >>>> Keith Thompson <kst-u@mib.org> writes:
> >>>>
> >>>>> [When using . or ->, what is "accessed"?]
> >>>>>
> >>>>> Let me make the point more succinctly.
> >>>>>
> >>>>> struct s { int m; };
> >>>>> struct s obj;
> >>>>> obj.m = 42;
> >
> > ...
> >
> >>> Let's consider the original struct.
> >>>
> >>> N1570 3.1 defines "access" as
> >>>
> >>> <execution-time action> to read or modify the value of an object
> >>>
> >>> Wouldn't you agree that `obj.m = 42;` modifies the value of obj?
> >>
> >> 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.
> >
> > ...
> >
> >> Which object, or objects, are accessed by a given lvalue expression
> >> should be the same whether the expression is used for reading or
> >> writing. Following this principle, I conclude that 'obj.m = 42;'
> >> accesses only the member, not the object of the struct.
> >
> > I've a series of questions that I'd like you to answer, with a goal
> > of better understanding what it is you mean by that. I'll modify
> > Keith's example, because the fact that 'm' is the only member of
> > 'obj' muddles some of the issues I'm trying to ask you about.
> > Given
> >
> > struct {int i; double *p} obj = {5, NULL};
> >
> > obj.i = 3;
> > double d;
> > obj.p = &d;
> >
> > What was the last value stored in obj before the first assignment?
>
> I don't know if an initialization is meant to count as storing a
> value or not. (I guess the first "Semantics" paragraph in the
> section on initialization says that it is.) If an initialization
> is meant to count as storing a value, or values, I don't know if
> it is meant to store values in individual members, or the struct
> object as a whole. If an initialization of a struct is meant to
> count as storing a value in the struct object as a whole, then
> the last value stored is a struct value whose first component is
> 5 of type int and whose second component is a null pointer of
> type double *.
>
> > What was the last value stored in obj between the two assignments?
>
> The assignment 'obj.i = 3;' stores an int value into the member
> object 'obj.i'. There is no assignment that stores a struct
> value into the struct 'obj'. I'm not sure what meaning you
> intend for the phrase "last value stored". The Standard seems
> to use the phrase "value stored" in different ways in different
> places, so I'm not sure what meaning to attach to the question.
>
> > What was the last value stored in obj after the second assignment?
>
> Same as the last answer, except that the assignment stores a
> pointer value into the member object 'obj.p'.
>
> > Which expressions, if any, caused a new value to be stored in obj?
>
> I don't know if you mean "stored" in the sense of "held" or
> "stored" in the sense of "delivered into".
>
> > Which expressions, if any, modified the value of obj?
>
> If you mean "modify" in the sense it is used in the definition of
> "access", as access is used in 6.5 p{6,7}, none of them. If you
> mean "modify" in some different sense, I don't know what sense
> that is.
He is as incompetent as DFS. But DFS feels the need to please the cult-like herd of convenient friends. So be it. Not only did Shawn Ulman's question fail to touch on the "kernel", it has nada to do with C++. DFS should learn to read ;) My uptime is almost seventy-nine days and C++ is still going strong! Frankly I do not really think you understand.
--
Curious how these posts are made? Email: mr@sandman.net
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-03 14:19 -0800 |
| Message-ID | <6e1d8745-4f73-4341-87a1-603745773bf0@googlegroups.com> |
| In reply to | #127301 |
On Saturday, March 3, 2018 at 2:58:46 AM UTC-6, Tim Rentsch wrote:
> Keith Thompson <kst-u@mib.org> writes:
> > 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.
>
> I don't subscribe to this view, more specifically the last
> sentence. Consider a union rather than a struct:
>
> typedef union {
> unsigned u;
> float f;
> double d;
> long unsigned lu;
> } X;
> X x;
> ...
> x.u
>
> In the space occupied by the memory for the identifier x, there
> are five objects - the union X x, the unsigned x.u, the float x.f,
> the double x.d, and the long unsigned x.lu. Which of those
> objects is accessed by evaluating the expression 'x.u'? To me it
> doesn't make sense to say the union object x is accessed but
> some of its members are not. But accessing all the members
> clearly leads to a violation of effective type rules, not to
> mention potential trap representations. The idea that accessing
> an object implies accessing all other objects whose memory
> regions overlap the designated object doesn't really fit with
> what all else the Standard describes. I don't think this is
> just a simple oversight in effective type rules.
Saying that an access to a region hits everything it occupies would
fit just fine if the Standard recognized that an lvalue or pointer
can be derived from an lvalue or pointer of a larger type. If one
considers things in those terms, attributing actions made on a
derived lvalue to the original in places where the derivation is
visible, and if one says that within a particular context storage
which is accessed via lvalue of one type shall not be made by an
lvalue that is neither of, nor visibly derived from, such a type,
then things will make a *lot* of sense.
If one requires that compilers derived objects be recognized in contexts
where the code that derives them is visible, and requires that derived
objects only be used either in the context where they are derived or in
those where there are no conflicting accesses a compiler would have to
worry about, such a rule would be an excellent balance between what
compilers can see and what they need to know.
From a 1980s compiler-design standpoint, all a compiler would need to do
to recognize derived lvalues is to treat the derivation of an lvalue from
another as an indication to the optimizer to treat the derivation as it
would an arbitrary access to the storage in question [but without having
to generate machine code to do such an access]. More sophisticated
compilers would need slightly fancier logic, but if language rules don't
require compilers generating code for a function or loop to worry about
any references derived outside it interacting with any actions in the
loop that don't involve those references, the remaining cases really
aren't that hard.
> My own (informal) rule is an lvalue of scalar type accesses just
> the one scalar object, and an lvalue of struct or union type
> accesses the struct or union object as a whole, and also "sort
> of" accesses all the member objects, but these cases never access
> an overlapping object, as for example might occur with a union
> member (eg, that is itself a struct or union). To be sure, an
> access of one object may read, or write, some of the same memory
> region of another object, but that doesn't count as an access for
> the purposes of 6.5 p7. Two clarifications: one, access through
> character types may be different; and two, I say a struct/union
> lvalue "sort of" accesses the members because struct/union types
> are exempt from having trap representations, which could be a
> problem if the members were "truly" accessed.'
What does it mean to take the address of a union member? What is the
resulting pointer value good for?
> > 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).
>
> It's highly unlikely it's just an oversight. Among other things,
> this clause
>
> an aggregate or union type that includes one of the
> aforementioned types among its members (including,
> recursively, a member of a subaggregate or contained union)
>
> has been present in the Standard since at least 1989.
The C language was described at a time when its semantics were very
literal, and its terminology suffered as a result. If one treats
something like "myUnion.x=3" as being an action upon the object
myUnion, then the quoted rule is necessary to make clear that the
operation is allowed to affect the values stored in other values of
myUnion.
> Note by the way that this clause is consistent with the informal
> view I described above - accessing a /containing/ object accesses
> its /contained/ objects, but accessing a /contained/ object does
> not access its /containing/ object (and never objects that simply
> happen to overlap, where neither contains the other). Bytes of
> another object's memory region may be read or written, but that
> does not constitute an access for the purposes of 6.5p7.
Accessing the stored value of a contained object *does* access the
stored value of any containing objects [and, in the case of unions,
the stored values of other contained objects as well]. Whether or
not that should be allowed in any particular case should vary
depending upon which of three cases applies in a particular context:
1. The compiler knows about the child but knows nothing about
any way the parent might be used to access what happens to
be the same storage as the child, in which case behavior
should be defined since there would be no conflict.
2. The compiler can see how the child is derived from the parent,
in which case the behavior should be defined since a non-blind
compiler will be able to avoid the conflict.
3. The compiler knows about accesses made to the parent and to
the child, and those accesses would conflict, but that could
not be determined from the section of code the compiler is
processing. In this case, the behavior need not be defined.
Nice, easy, and simple.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-01 18:03 -0800 |
| Message-ID | <9fe1a7c0-c357-4251-a634-99d16bd43a90@googlegroups.com> |
| In reply to | #127213 |
On Thursday, March 1, 2018 at 5:38:32 PM UTC-7, supe...@casperkitty.com wrote:
> For purposes of 6.5p7, what would be the types of the lvalues on the left
> side of each numbered assignment in the code below [assume store_int is
> called exclusively from test3]?
>
> struct S {int x[1];};
> int *p;
>
> void test1(struct S *s) {
> s->x[0] = 1; // #1
> }
>
> void test2(struct S *s)
> {
> int *p = s->x;
> *p = 2; // #2
> }
>
> static void store_int(int *p)
> {
> *p = 3; // #3 -- when invoked from test3
> }
> void test3(struct S *s)
> {
> store_int(s->x);
> }
>
> So far as I can tell, for code to have defined behavior one of the
> following would need to be true for each of the assignments that stores
> a value 1 to 3.
>
> 1. They operate upon an lvalue of type "int", but don't use it to access
> the stored value of a "struct S" object [even though it sure looks like
> they do clearly do], or...
>
> 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.
>
> 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...
>
> 4. The assignments invoke UB because of 6.5p7.
>
> Statements #1 and #2 don't seem to represent any consistent philosophy,
> and #4 is Just Plain Dumb. Statement #3 would seem like a practical
> way to define things, except that I don't see anything in the Standard
> that suggests that an lvalue can have one type for the purposes of 6.5p7
> and a different type for the purposes of 6.5.3.2, nor anything that
> describes the circumstances in which a pointer keeps or loses a "6.5p7
> type" which is different from its "6.5.3.2 type".
I thought showing him I know where he lives might help the situation. It did not. Having to endure the use of System76 it can hardly be called "free" when you include your time.
Being self-governed as it is, usenet will never go away but it'll never be well known. This is what happens when acutely poor self-respect takes over Adam LeMond's entire life.
--
E-commerce Simplified!
http://alt.conspiracy.narkive.com/QcWYJ4Px/the-mentally-ill-mark-s-bilk
Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2018-03-21 10:33 -0700 |
| Message-ID | <b00073b0-e90f-4f50-9aa3-a8527faae50a@googlegroups.com> |
| In reply to | #127213 |
On Thursday, March 1, 2018 at 6:38:32 PM UTC-6, supe...@casperkitty.com wrote:
> For purposes of 6.5p7, what would be the types of the lvalues on the left
> side of each numbered assignment in the code below [assume store_int is
> called exclusively from test3]?
>
> struct S {int x[1];};
> int *p;
>
> void test1(struct S *s) {
> s->x[0] = 1; // #1
> }
>
> void test2(struct S *s)
> {
> int *p = s->x;
> *p = 2; // #2
> }
>
> static void store_int(int *p)
> {
> *p = 3; // #3 -- when invoked from test3
> }
> void test3(struct S *s)
> {
> store_int(s->x);
> }
>
> So far as I can tell, for code to have defined behavior one of the
> following would need to be true for each of the assignments that stores
> a value 1 to 3.
>
> 1. They operate upon an lvalue of type "int", but don't use it to access
> the stored value of a "struct S" object [even though it sure looks like
> they do clearly do], or...
>
> 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.
>
> 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...
>
> 4. The assignments invoke UB because of 6.5p7.
>
5. The *member object* of the aggregate type may be modified using an lvalue of
that type.
Each member of a struct is an object in its own right (6.2.5/20). When you assign to
s->x[0], you're only modifying that specific element of that specific member, which has
type int - you are not modifying the *entire* struct object with that assignment.
There's no oversight in the wording of the standard, and there's no UB. The object in
question is s->x[0], not s.
> Statements #1 and #2 don't seem to represent any consistent philosophy,
> and #4 is Just Plain Dumb. Statement #3 would seem like a practical
> way to define things, except that I don't see anything in the Standard
> that suggests that an lvalue can have one type for the purposes of 6.5p7
> and a different type for the purposes of 6.5.3.2, nor anything that
> describes the circumstances in which a pointer keeps or loses a "6.5p7
> type" which is different from its "6.5.3.2 type".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-21 11:53 -0700 |
| Message-ID | <lnk1u5p8el.fsf@kst-u.example.com> |
| In reply to | #128162 |
John Bode <jfbode1029@gmail.com> writes:
[...]
> Each member of a struct is an object in its own right (6.2.5/20).
Yes.
> When you assign to s->x[0], you're only modifying that specific
> element of that specific member, which has type int - you are not
> modifying the *entire* struct object with that assignment.
You're not necessarily modifying the entire struct object, but you are
modifying part of it.
> There's no oversight in the wording of the standard, and there's no
> UB. The object in question is s->x[0], not s.
So you're saying that
s->x = 42;
modifies the member x (which is of type int), but it doesn't modify the
object *s (which is of some struct type)? Doesn't that struct object
have a different value after the assignment than before it? Isn't that
a modification, and therefore an access, of the struct object?
If I do this:
int n = 42;
*(unsigned char*)&n = 0;
am I not modifying the value of n? (Assume if you like that
sizeof (int) > 1).
--
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"
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-22 00:11 -0700 |
| Message-ID | <7f6aed93-5434-4880-8770-6aa93d52dafc@googlegroups.com> |
| In reply to | #128166 |
On Wednesday, March 21, 2018 at 11:53:49 AM UTC-7, Keith Thompson wrote: > John Bode <jfbode1029@gmail.com> writes: > [...] > > Each member of a struct is an object in its own right (6.2.5/20). > > Yes. > > > When you assign to s->x[0], you're only modifying that specific > > element of that specific member, which has type int - you are not > > modifying the *entire* struct object with that assignment. > > You're not necessarily modifying the entire struct object, but you are > modifying part of it. > > > There's no oversight in the wording of the standard, and there's no > > UB. The object in question is s->x[0], not s. > > So you're saying that > > s->x = 42; > > modifies the member x (which is of type int), but it doesn't modify the > object *s (which is of some struct type)? Doesn't that struct object > have a different value after the assignment than before it? Isn't that > a modification, and therefore an access, of the struct object? > > If I do this: > > int n = 42; > *(unsigned char*)&n = 0; > > am I not modifying the value of n? (Assume if you like that > sizeof (int) > 1). > > -- > 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" Audra Moore's computer has more hard drives than John 'The Shill' Gohde's. Audra Moore wins. John 'The Shill' Gohde loses. Which gives Audra Moore better productivity, efficiency, and error-reduction. Reviewing Linux... even now a rookie... Audra Moore owns John 'The Shill' Gohde in every way possible. I think the person you are replying to is in my kill file. -- Do not click this link!! http://www.macadvocacy.pw/2005/Nov/09/236626.html Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-21 11:53 -0700 |
| Message-ID | <28d563d6-0884-421f-91f0-66096fa32f93@googlegroups.com> |
| In reply to | #128162 |
On Wednesday, March 21, 2018 at 12:33:21 PM UTC-5, John Bode wrote:
> 5. The *member object* of the aggregate type may be modified using an lvalue of
> that type.
>
> Each member of a struct is an object in its own right (6.2.5/20). When you assign to
> s->x[0], you're only modifying that specific element of that specific member, which has
> type int - you are not modifying the *entire* struct object with that assignment.
How is that different from:
> On Thursday, March 1, 2018 at 6:38:32 PM UTC-6, supe...@casperkitty.com wrote:
> > 1. They operate upon an lvalue of type "int", but don't use it to access
> > the stored value of a "struct S" object [even though it sure looks like
> > they do clearly do], or...
> There's no oversight in the wording of the standard, and there's no UB. The object in
> question is s->x[0], not s.
Are you saying that given:
struct s {unsigned x;} s1,s2,*p;
... assign p somehow, and then ...
s1 = *p;
p->x++;
s2 = *p;
one should expect that the values of s1 and s2 will be equal, since the
operation on p->x doesn't affect the stored value of *p?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-03-26 23:04 -0700 |
| Message-ID | <kfnsh8mm4vb.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #128162 |
John Bode <jfbode1029@gmail.com> writes:
> On Thursday, March 1, 2018 at 6:38:32 PM UTC-6, supe...@casperkitty.com wrote:
>
>> For purposes of 6.5p7, what would be the types of the lvalues on the left
>> side of each numbered assignment in the code below [assume store_int is
>> called exclusively from test3]?
>>
>> struct S {int x[1];};
>> int *p;
>>
>> void test1(struct S *s) {
>> s->x[0] = 1; // #1
>> }
>>
>> void test2(struct S *s)
>> {
>> int *p = s->x;
>> *p = 2; // #2
>> }
>>
>> static void store_int(int *p)
>> {
>> *p = 3; // #3 -- when invoked from test3
>> }
>> void test3(struct S *s)
>> {
>> store_int(s->x);
>> }
>>
>> So far as I can tell, for code to have defined behavior one of the
>> following would need to be true for each of the assignments that stores
>> a value 1 to 3.
>>
>> 1. They operate upon an lvalue of type "int", but don't use it to access
>> the stored value of a "struct S" object [even though it sure looks like
>> they do clearly do], or...
>>
>> 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.
>>
>> 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...
>>
>> 4. The assignments invoke UB because of 6.5p7.
>
> 5. The *member object* of the aggregate type may be modified using an lvalue of
> that type.
>
> Each member of a struct is an object in its own right (6.2.5/20). When you assign to
> s->x[0], you're only modifying that specific element of that specific member, which has
> type int - you are not modifying the *entire* struct object with that assignment.
>
> There's no oversight in the wording of the standard, and there's no UB. The object in
> question is s->x[0], not s.
That's basically what I've been saying.
[toc] | [prev] | [standalone]
Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
Back to top | Article view | comp.lang.c
csiph-web