Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #128669
| Newsgroups | comp.lang.c |
|---|---|
| Date | 2018-04-03 12:19 -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 | <f22455ea-6bf6-4e34-9efc-2f268dacca82@googlegroups.com> (permalink) |
| Subject | Re: lvalue types |
| From | supercat@casperkitty.com |
On Tuesday, April 3, 2018 at 1:33:27 PM UTC-5, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> > They are, but the assignment to *ptr involves the lvalue "obj" in a way
> > which would be visible to any compiler that makes any effort to see it.
>
> Compilers are not required to make that effort, but that's not relevant
> anyway. Even if `*ptr = 42` involves an lvalue of type `struct s`, it
> doesn't matter whether the compiler is able to determine that it does.
> The effective type rules describe which accesses do or do not have
> defined behavior.
The stated purpose of the rules is to allow compilers to make assumptions
about what things do and do not alias. If a derived pointer were used to
access some storage at a time after some other pointer not derived from it
was used in a fashion related to the storage, it would alias that other
pointer. Use of references to derive other references in LIFO fashion,
however, is not aliasing in any normal sense of the word.
All a compiler that caches values in registers would need to do to handle
this situation is flush any cached registers associated with the union
object whenever the address-of operator is applied to a member thereof,
and note that the resulting pointer is associated with the original lvalue
(so any registers associated with it can be flushed the next time that
lvalue is accessed).
Such a thing would have been trivial when the Standard was written, and I
see no reason to believe the authors of the Standard expected compiler
writers would design their compilers so as to be incapable of doing so.
> If we were to argue that `*ptr = 42` involves an lvalue of type
> `struct s`, that argument would be based on the lvalue(s) in the
> expression being "derived" from an lvalue of type `struct s`,
> not on whether the compiler knows that.
The only times a compiler would need to really keep track of anything would
be when a parent lvalue is used after a derived lvalue, in which case it
would need to make sure the cached derived lvalue was retired before the
next use of the parent. If one allows retirement of an lvalue that was
derived before the start of a function or loop to be hoisted up to the start
of that function or loop [implying a requirement that any storage accessed
by an lvalue derived before the start of a particular execution of a
function or loop must be accessed exclusively via that lvalue or others
derived from it *during* that execution] a simple static analysis of the
syntax tree would suffice to identify places where cached lvalues need
to be flushed.
> > The address-of operator would be rather silly if it didn't allow a derived
> > lvalue to be used to access storage within the parent at least in cases
> > where it is the most recently derived lvalue that will be used to access
> > the storage in question, and a non-blind compiler can see its derivation.
>
> In the assignment `*ptr = 42`, the value of obj is not modified "by" the
> lvalue `obj` that appears on a previous line. The only lvalues in that
> assignment are `ptr` (which undergoes lvalue conversion, yielding a
> value of type int*) and `*ptr` (which is used to access obj.m).
So if I copy "obj" to s1 before the assignment to *ptr, and I copy it to
s2 after, then s1 and s2 will end up holding the same values?
> 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.
All that would be necessary would be to say that accesses must "use" an
lvalue of the proper type, for a reasonable definition of "use". Note
that under a literal reading of the Standard, even something like:
char ch;
ch=5;
would invoke Undefined Behavior, because the lvalue ch doesn't modify
the storage, and the expression that does modify the storage isn't an
lvalue.
By your reading of the Standard, given:
struct s1 {int x1; ...};
struct s2 {int x2; ...};
int test1(struct s1 *p1, struct s2 *p2)
{
struct s2 *p2b = (struct s2*)p2;
if (p1->x1)
p2b->x2 += 4;
return p1->x1;
}
int test2(struct s1 *p1, struct s1 *p2)
{
if (p1->x1)
{
struct s2 *p2b = (struct s2*)p2;
p2b->x2 += 4;
}
return p1->x1;
}
for which function, if either, would a compiler be required to acknowledge
that p1 and p2 might identify the same storage? My interpretation of your
reading is that p1->x1 is simply an lvalue expression of type "int", and
likewise p2b->x2, and thus a compiler would be required to allow for
aliasing between them. GCC's behavior would not recognize it in either
case. By my reading, invoking test1 with matching pointers p1 and p2 would
result in aliasing between p2b and p1 (since p1 is not derived from p2b,
but is used between the time p2b is derived and when it is used), but test2
would not (since p2b would be created after the first use of p1->x, and
all uses of p2b would precede the next use of p1->x). All a compiler would
need to do to make the second code work is recognize the second as:
int test2(struct s1 *p1, struct s1 *p2)
{
if (p1->x1)
{
...Retire any cached lvalues that might match p2 [including
...anything of "struct s1" which p2 might identify, such as *p1].
struct s2 *p2b = (struct s2*)p2;
...Recognize p2b as a cached lvalue that might match p2
p2b->x2 += 4;
}
... Retire any cached lvalues that might match p1 [including
... anything of "struct s1" which p1 might identify, such as *p2
... or things derived from it, like p2b].
return p1->x1;
}
True, I'd interpret the footnote as normative, but that seems less of a
stretch than pretending that objects aren't accessed in cases where they
clearly are.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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 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 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 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
csiph-web