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 | 20 on this page of 150 — 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 Tim Rentsch <txr@alumni.caltech.edu> - 2018-06-14 02:53 -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 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-04-09 08:31 -0700 |
| Message-ID | <kfnfu44cs6a.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #128745 |
jameskuyper@verizon.net writes: I've been thinking over your comments and have started on putting together a response. Not ready to write that yet but hope to be soon.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-04-11 11:19 -0700 |
| Message-ID | <kfnvacxbo6r.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #128745 |
jameskuyper@verizon.net writes:
> [questions concerning "modify", "store", "access", "value", and
> "object", and making sense of how those terms are used in the
> ISO C standard]
I've gone over your followup comments again while thinking about
how to respond. It seems likely that there are some fundamental
assumptions that we have made differently. I suspect in fact that
your questions are downstream of these assumptions, and that is a
lot of why we are having trouble communicating. To help with that,
my idea is to explain what I think are my key assumptions, which
might let us see where the sticking point it.
The first point is about "value". A "value" is something abstract,
such as the number 3. Memories in computers (and also in the
abstract machine) don't hold "values", they hold representations
of "values". The Standard agrees with this view, as evidenced by
its definition of "object"
object
region of data storage in the execution environment, the
contents of which can represent values
The second point is about "object". An "object" is more than just
a region of memory. For example, a member of a struct and the
struct as a whole are distinct "objects", even if they happen to
occupy exactly the same region of memory. Or, another example,
members of a union: different members of a union are always
distinct objects, even if their sizes are the same (which implies
they occupty the same region of memory). Which "object" is being
referenced depends on where the reference comes from. That makes
things complicated. Consider the following code fragment
(disclaimer: all code examples simply typed in, not compiled):
void *p = malloc( 1024 );
((unsigned short *)p)[1] = 17;
(To simplify the discussion we assume the malloc() succeeds, the
implementation has 8-bit bytes, two-byte shorts, four-byte ints,
no padding bits, etc. Also for the time being we will ignore
any questions concerning using character types.)
Simple question: which "object", or "objects", does the assignment
modify? Depending on one's assumptions, the answer might be "not
known", "not knowable", "a mind-bogglingly large number", or
something else. In particular, if we assume that an assigment
"modifies" any "object" that might overlap the bytes directly
affected by the assignment, then at the very least there are an
awful lot of possibilities. (I should say explicitly that this
question and others like it below are meant to be rhetorical.)
Here is another example:
union foo { unsigned u; float f; } uf;
uf.u = -17;
Does the assignment to 'uf.u' modify the "object" of the member
'uf.f'? If it does, and the object representation for the assigned
value corresponds to a trap representation for the type float (we
are assuming the two members have the same size), does that mean
this assignment transgresses into undefined behavior.
Here is another example:
union food { unsigned u; float f; double d; } ufd;
struct bas { unsigned u; int i; } ui;
unsigned *p = malloc( sizeof ufd + sizeof ui );
*p = -7;
ufd = *(union food *)p;
ui = *(struct bas *)p;
First question: what "objects" are there in the space allocated by
malloc()? (Again we are assuming the malloc() succeeds.) Are they
there to begin with, or do the assignments change things? Does the
space hold both a union "object" and a struct "object" at the same
time, or does it hold a union "object" at one time and a struct
"object" at another time? Or does it ever hold a union "object" or
a struct "object"?
Second question: are the second and third assignments even allowed
under the Standard? If they are, where does the union "value" or
struct "value" come from? No union "value" was ever present in the
program before one was materialized out of the allocated space.
Nor was any struct "value" present in the program before one was
materialized out of the allocated space. Does the first assignment
'*p = -7' somehow cause such "values" to spring into existence, or
were there some sort of "values" there all along?
For me most of these perplexing questions don't come up. That
happens because of two key assumptions. The first assumption is
that the word "object" is used in the Standard with very different
meanings in different places. Like a ski resort where there are
young girls looking for husbands and husbands looking for young
girls, the same word can mean quite different things depending on
context. Context is crucial.
The second assumption has to do with "objects" existing. In most
cases having to do with expressional contexts, we only know an
object is there when there is an lvalue that designates it. (This
might be called a quantum mechanial view: we can't say anything
about an "object" unless we're observing it.) This assumption
clears up a great many problems: when "storing" a "value", we
always know what kind of "value" is being "stored", by virtue of
the type of the lvalue that designates the "object"; also, we know
just what "object" is being modified, because the "object" that the
lvalue designates is the only "object" there is.
Of course what this leaves is the matter of 6.2.4 p2, which says in
part that an "object"
retains its last-stored value throughout its lifetime.
(Note that 'last-stored' is a hyphenated adjective modifying the
term-of-discussion "value".)
For structs, and also unions, this is problematic. One problem is
that the "value" may be updated piecemeal (true even in a union,
where a member may be an array). A second problem is that the
struct or union "object" may have never gotten a "value" in the
first place. It's fairly common for structs or unions not to be
assigned as a whole but only have assignments to their members.
However, the only time these problems matter is when we are
performing an lvalue conversion on the struct or union as a whole.
If we assume that structs (and unions) don't "store" "values" in
the usual sense, but rather, for lvalue conversion, synthesize a
"value" out of the "values" of their component elements (and of
course doing that recursively), then we don't need to worry about
what changing a member does to the struct as a whole - it falls out
of what is meant by doing lvalue conversion of a struct or union
type.
To completely flesh this out I would need to talk about arrays
and character types, and maybe bitfields. However I don't think
doing that is especially challenging and I expect you can fill
in all the blanks there.
I have now put a fair amount of effort into writing this, so I
hope it was helpful.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-11 12:44 -0700 |
| Message-ID | <12588cdc-c888-4447-8be5-1cdc1c1825b4@googlegroups.com> |
| In reply to | #129084 |
On Wednesday, April 11, 2018 at 1:20:10 PM UTC-5, Tim Rentsch wrote:
> Simple question: which "object", or "objects", does the assignment
> modify? Depending on one's assumptions, the answer might be "not
> known", "not knowable", "a mind-bogglingly large number", or
> something else. In particular, if we assume that an assigment
> "modifies" any "object" that might overlap the bytes directly
> affected by the assignment, then at the very least there are an
> awful lot of possibilities. (I should say explicitly that this
> question and others like it below are meant to be rhetorical.)
I think the most logical way of specifying this would be to say that
it accesses all objects that would be in any type the storage could
contain *but* given that the rationale and footnote the only objects
that should be *relevant* for purposes of 6.5p7 would be those whose
value changes during the same particular execution of a function or
loop, and which are accessed during that execution using an lvalue of
their type.
Given something like:
void foo(int *p) { *p = 1; }
a compiler generating stand-alone code for "foo" should have no reason to
know or care about the types of any objects whose storage might be affected
by "p". If the pointer is derived from an lvalue of another type (e.g.
"foo(&bar.boz)") then a compiler would need to recognize any accesses made
to the target of the passed-in "int*" as affecting bar.boz [and thus bar] or
allow for the possibility of foo accessing bar.boz in arbitrary fashion.
Stand-alone code for "foo", however, need not know nor care about the
existence of such types in calling code.
> Here is another example:
>
> union foo { unsigned u; float f; } uf;
> uf.u = -17;
>
> Does the assignment to 'uf.u' modify the "object" of the member
> 'uf.f'? If it does, and the object representation for the assigned
> value corresponds to a trap representation for the type float (we
> are assuming the two members have the same size), does that mean
> this assignment transgresses into undefined behavior.
As the Standard is written, it does.
> Here is another example:
>
> union food { unsigned u; float f; double d; } ufd;
> struct bas { unsigned u; int i; } ui;
> unsigned *p = malloc( sizeof ufd + sizeof ui );
> *p = -7;
> ufd = *(union food *)p;
> ui = *(struct bas *)p;
>
> First question: what "objects" are there in the space allocated by
> malloc()? (Again we are assuming the malloc() succeeds.) Are they
> there to begin with, or do the assignments change things? Does the
> space hold both a union "object" and a struct "object" at the same
> time, or does it hold a union "object" at one time and a struct
> "object" at another time? Or does it ever hold a union "object" or
> a struct "object"?
Every object that could fit and be alignment-compatible with any particular
region of storage exists there simultaneously, but will have no effect on
anything if no lvalue of the type in question is used to access the storage.
> Second question: are the second and third assignments even allowed
> under the Standard? If they are, where does the union "value" or
> struct "value" come from? No union "value" was ever present in the
> program before one was materialized out of the allocated space.
> Nor was any struct "value" present in the program before one was
> materialized out of the allocated space. Does the first assignment
> '*p = -7' somehow cause such "values" to spring into existence, or
> were there some sort of "values" there all along?
They were there all along, though they only become relevant when an
lvalue of suitable type is produced.
> For me most of these perplexing questions don't come up. That
> happens because of two key assumptions. The first assumption is
> that the word "object" is used in the Standard with very different
> meanings in different places. Like a ski resort where there are
> young girls looking for husbands and husbands looking for young
> girls, the same word can mean quite different things depending on
> context. Context is crucial.
The only place where the definition of "object" poses a problem is the
use in 6.5p7, which should (but doesn't) limit to objects that are
accessed in ways that involve lvalues of their type.
> The second assumption has to do with "objects" existing. In most
> cases having to do with expressional contexts, we only know an
> object is there when there is an lvalue that designates it. (This
> might be called a quantum mechanial view: we can't say anything
> about an "object" unless we're observing it.) This assumption
> clears up a great many problems: when "storing" a "value", we
> always know what kind of "value" is being "stored", by virtue of
> the type of the lvalue that designates the "object"; also, we know
> just what "object" is being modified, because the "object" that the
> lvalue designates is the only "object" there is.
In the absence of 6.5p7 there would be no difficulty whatsoever saying that
all storage is simultaneously occupied by every type of object that will
fit and is alignment compatible, and the value of any object is encapsulated
by the bits held in that storage. Restricting 6.5p7 to objects that could
possibly be involved in aliasing, and recognizing a broad concept of "using"
an lvalue, will solve a lot of problems.
> Of course what this leaves is the matter of 6.2.4 p2, which says in
> part that an "object"
>
> retains its last-stored value throughout its lifetime.
>
> (Note that 'last-stored' is a hyphenated adjective modifying the
> term-of-discussion "value".)
>
> For structs, and also unions, this is problematic. One problem is
> that the "value" may be updated piecemeal (true even in a union,
> where a member may be an array). A second problem is that the
> struct or union "object" may have never gotten a "value" in the
> first place. It's fairly common for structs or unions not to be
> assigned as a whole but only have assignments to their members.
> However, the only time these problems matter is when we are
> performing an lvalue conversion on the struct or union as a whole.
> If we assume that structs (and unions) don't "store" "values" in
> the usual sense, but rather, for lvalue conversion, synthesize a
> "value" out of the "values" of their component elements (and of
> course doing that recursively), then we don't need to worry about
> what changing a member does to the struct as a whole - it falls out
> of what is meant by doing lvalue conversion of a struct or union
> type.
One can also solve the problem by noting that an operation on an lvalue
which is derived from and actively associated with another one that
identifies a particular object is an operation on that object. No version
of the Standard has specified any cases where compilers must recognize such
association--not even the most trivial. I guess the authors didn't think
they needed to order compiler writers to exercise what they thought was
common sense.
If one were to recognize a few principles that would have been common sense
in 1989 (e.g. only the lvalue types that are used to access a particular
piece of storage within a particular execution of a loop or function should
matter during that particular execution, and an lvalue which is derived from
another should be presumed capable of accessing the same object), that would
eliminate the need for the notion of "effective type", and would allow use
of the "character-type" exception to be deprecated.
Given:
void bump1(unsigned long *p, unsigned long *q)
{
if (*p) *(unsigned char*)q=1;
return *p;
}
void bump2(unsigned long *p, unsigned char *q)
{
if (*p) *q=1;
return *p;
}
void bump3(unsigned long *p, unsigned long *q)
{
if (*p) *((unsigned short*)q)=1;
return *p;
}
void bump4(unsigned long *p, unsigned short *q)
{
if (*p) *q=1;
return *p;
}
I think it's clear that the authors of the Standard wanted bump1 to be
defined when p and q identify the same storage, and probably didn't think
bump4 needed to be defined in that case. The Standard defines the behavior
of bump2, but that pattern is a lot less common than bump1; since a cast of
a non-null non-void pointer is equivalent to taking the address of the
object identified thereby, a compiler should have no trouble recognizing
that the lvalue derived from q in test3() might access something of q's
type.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2018-04-12 06:45 -0700 |
| Message-ID | <117929cb-d6aa-45bc-a5d4-8566bb8c6d58@googlegroups.com> |
| In reply to | #129084 |
On Wednesday, April 11, 2018 at 2:20:10 PM UTC-4, Tim Rentsch wrote: > jameskuyper@verizon.net writes: > > > [questions concerning "modify", "store", "access", "value", and > > "object", and making sense of how those terms are used in the > > ISO C standard] That's not quite an accurate summary of what I said. I'm not asking about what those terms mean in the standard, nor how to make sense of the way the standard uses those terms. I believe I understand quite well the way that it uses them, and in particular, I understand that some of what the standard says is badly worded, so it doesn't say quite what I think that the committee wanted it to say. I believe that the standard means what it actually says, even when what it actually says doesn't mean what the committee intended it to mean. When that is the case, I consider it a defect in the standard that needs correcting, not a justification for twisting the meaning of the relevant terms so that what it actually says ends up matching what it should have said. In particular, if the standard uses a term inconsistently, what that usually means is that at least one of those uses was incorrect, not that the term was intended to simultaneously have multiple incompatible meanings, with the correct one to be divined from context. What I'm asking about is how you understand those terms, to justify the weird way in which you use them to interpret the standard. I don't have any significant doubts about the accuracy of my understanding, which differs from yours. But until I understand what's different about the way you think about these matters, I can't rule out the possibility that you're right. On the flip side, if I do end up ruling out that possibility, a better understanding of your point of view might help me figure out how to correct it. ... > of "values". The Standard agrees with this view, as evidenced by > its definition of "object" > > object > region of data storage in the execution environment, the > contents of which can represent values > > The second point is about "object". An "object" is more than just > a region of memory. For example, a member of a struct and the > struct as a whole are distinct "objects", even if they happen to They are different objects, but I emphatically disagree that they are distinct objects. A member has an object representation that is a sub-set of the object representation of the struct it's a member of. When the object representation of a member is changed to represent a different value, the object representation of the containing struct has also changed, so the value represented by that struct has changed. > occupy exactly the same region of memory. ... > For me most of these perplexing questions don't come up. That > happens because of two key assumptions. The first assumption is > that the word "object" is used in the Standard with very different > meanings in different places. ... It would be very helpful if, instead of simply asserting that the standard uses a term inconsistently, you could identify specific uses that are inconsistent, and explain what the two or more different meanings actually are. ... > The second assumption has to do with "objects" existing. In most > cases having to do with expressional contexts, we only know an > object is there when there is an lvalue that designates it. (This > might be called a quantum mechanial view: we can't say anything > about an "object" unless we're observing it.) This assumption > clears up a great many problems: when "storing" a "value", we > always know what kind of "value" is being "stored", by virtue of > the type of the lvalue that designates the "object"; also, we know > just what "object" is being modified, because the "object" that the > lvalue designates is the only "object" there is. > > Of course what this leaves is the matter of 6.2.4 p2, which says in > part that an "object" > > retains its last-stored value throughout its lifetime. I think this requirement is inconsistent with your concept of an object existing only when it's looked at: if it flickers out of existence when you stop looking at it, it can no longer retain the value that it's required to retain. Now, the as-if rule allows an implementation to arbitrarily modify an object at any time, so long as it modifies it back again before the next time it's value is read, but that's not the way things work in the abstract machine. It's only a permitted optimization; and it's only permitted if the implementation can make absolutely certain that it will never have any effect on the observable behavior of the program, which must be the same as if it didn't happen. > (Note that 'last-stored' is a hyphenated adjective modifying the > term-of-discussion "value".) > > For structs, and also unions, this is problematic. One problem is > that the "value" may be updated piecemeal (true even in a union, > where a member may be an array). A second problem is that the > struct or union "object" may have never gotten a "value" in the > first place. It's fairly common for structs or unions not to be > assigned as a whole but only have assignments to their members. > However, the only time these problems matter is when we are > performing an lvalue conversion on the struct or union as a whole. > If we assume that structs (and unions) don't "store" "values" in > the usual sense, but rather, for lvalue conversion, synthesize a > "value" out of the "values" of their component elements (and of > course doing that recursively), then we don't need to worry about > what changing a member does to the struct as a whole - it falls out > of what is meant by doing lvalue conversion of a struct or union > type. What you "don't need to worry about" is something that my approach has no problem with: modifying the value of a member of that struct is modification of the value of the struct as a whole, and the fact that this leads to the conclusion that certain perfectly ordinary code violates the anti-aliasing rule is explainable as an error in the wording of that rule, not as an indication that the committee intended such code to have undefined behavior, nor as a sign that the committee was using special meanings for certain terms that is incompatible with the meanings those terms have when used in other locations in the standard.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-12 07:54 -0700 |
| Message-ID | <33a55bca-4174-4e74-9444-8f7f2014b1ad@googlegroups.com> |
| In reply to | #129101 |
On Thursday, April 12, 2018 at 8:45:55 AM UTC-5, james...@verizon.net wrote:
> I believe that the standard means what it actually says, even when what
> it actually says doesn't mean what the committee intended it to mean.
> When that is the case, I consider it a defect in the standard that needs
> correcting, not a justification for twisting the meaning of the relevant
> terms so that what it actually says ends up matching what it should have
> said. In particular, if the standard uses a term inconsistently, what
> that usually means is that at least one of those uses was incorrect, not
> that the term was intended to simultaneously have multiple incompatible
> meanings, with the correct one to be divined from context.
If the Standard fails to define the behavior of a construct, but every
reasonable person would agree upon what should be a defined behavior,
should programmers regard the construct as unusable unless or until the
authors of the Standard get around to actually defining it?
Remember that the purpose of the Standard was not to define a new language,
but to codify an existing one, and the authors focused on places where
different implementations did things differently. Given something like:
struct foo {int x, y;} s;
...
s.y = 3;
there was never any doubt about how the assignment should behave on
platforms where "struct foo" would have no padding, and even on platforms
where it does have padding the only question would be whether an
implementation would be required to avoid disturbing it. The notion that
such code should be considered unusable in "Standard C" because it uses an
lvalue of type "int" to access an object of type "struct foo" would be
absurd if one intends "Standard C" to be a useful language.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-12 14:26 -0700 |
| Message-ID | <lnfu40nmkq.fsf@kst-u.example.com> |
| In reply to | #129102 |
supercat@casperkitty.com writes:
[...]
> If the Standard fails to define the behavior of a construct, but every
> reasonable person would agree upon what should be a defined behavior,
> should programmers regard the construct as unusable unless or until the
> authors of the Standard get around to actually defining it?
No, of course not.
> Remember that the purpose of the Standard was not to define a new language,
> but to codify an existing one, and the authors focused on places where
> different implementations did things differently. Given something like:
>
> struct foo {int x, y;} s;
> ...
> s.y = 3;
>
> there was never any doubt about how the assignment should behave on
> platforms where "struct foo" would have no padding, and even on platforms
> where it does have padding the only question would be whether an
> implementation would be required to avoid disturbing it.
Agreed.
> The notion that
> such code should be considered unusable in "Standard C" because it uses an
> lvalue of type "int" to access an object of type "struct foo" would be
> absurd if one intends "Standard C" to be a useful language.
Yes, that would be absurd, which is why (unless I've missed something)
nobody here has made such a claim.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-12 14:43 -0700 |
| Message-ID | <d8adbacf-1ad8-4e16-92ec-abebf4755eac@googlegroups.com> |
| In reply to | #129106 |
On Thursday, April 12, 2018 at 4:26:24 PM UTC-5, Keith Thompson wrote: > > The notion that > > such code should be considered unusable in "Standard C" because it uses an > > lvalue of type "int" to access an object of type "struct foo" would be > > absurd if one intends "Standard C" to be a useful language. > > Yes, that would be absurd, which is why (unless I've missed something) > nobody here has made such a claim. Perhaps I misunderstood what you meant by > > I believe that the standard means what it actually says, even when what > > it actually says doesn't mean what the committee intended it to mean. > > When that is the case, I consider it a defect in the standard that needs > > correcting, not a justification for twisting the meaning of the relevant > > terms so that what it actually says ends up matching what it should have > > said. If the Standard as written is meaningless, but a slight adjustment would make it meaningful, are you saying that the Standard should have simply been dismissed as meaningless, rather than used as the basis for something that would be usable? I suppose in retrospect that might have eventually resulted in the Committee writing something that could be useful as written, and avoided the mess they've created by their failure to do so, but the defects in the Standard wouldn't have caused any problem if compiler writers had interpreted UB as an invitation to look at precedents in similar compilers, rather than as an excuse to ignore them.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-12 17:40 -0700 |
| Message-ID | <ln7epcndkz.fsf@kst-u.example.com> |
| In reply to | #129109 |
supercat@casperkitty.com writes:
> On Thursday, April 12, 2018 at 4:26:24 PM UTC-5, Keith Thompson wrote:
>> > The notion that
>> > such code should be considered unusable in "Standard C" because it uses an
>> > lvalue of type "int" to access an object of type "struct foo" would be
>> > absurd if one intends "Standard C" to be a useful language.
>>
>> Yes, that would be absurd, which is why (unless I've missed something)
>> nobody here has made such a claim.
>
> Perhaps I misunderstood what you meant by
>
>> > I believe that the standard means what it actually says, even when what
>> > it actually says doesn't mean what the committee intended it to mean.
>> > When that is the case, I consider it a defect in the standard that needs
>> > correcting, not a justification for twisting the meaning of the relevant
>> > terms so that what it actually says ends up matching what it should have
>> > said.
That was James Kuyper, not me.
In any case, I didn't interpret what he wrote the way you did, though I
suppose I can see how you took it the way you did.
My own opinion is that a defect in the standard doesn't require us to
discard common sense. I wouldn't hesitate to rely on the behavior of
`obj.m = 42;`, and I don't think James would either.
--
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-04-13 03:02 -0700 |
| Message-ID | <63de4ba2-2cee-49bf-aa61-2c18bc943851@googlegroups.com> |
| In reply to | #129118 |
On Thursday, April 12, 2018 at 5:40:36 PM UTC-7, Keith Thompson wrote: > supercat@casperkitty.com writes: > > On Thursday, April 12, 2018 at 4:26:24 PM UTC-5, Keith Thompson wrote: > >> > The notion that > >> > such code should be considered unusable in "Standard C" because it uses an > >> > lvalue of type "int" to access an object of type "struct foo" would be > >> > absurd if one intends "Standard C" to be a useful language. > >> > >> Yes, that would be absurd, which is why (unless I've missed something) > >> nobody here has made such a claim. > > > > Perhaps I misunderstood what you meant by > > > >> > I believe that the standard means what it actually says, even when what > >> > it actually says doesn't mean what the committee intended it to mean. > >> > When that is the case, I consider it a defect in the standard that needs > >> > correcting, not a justification for twisting the meaning of the relevant > >> > terms so that what it actually says ends up matching what it should have > >> > said. > > That was James Kuyper, not me. > > In any case, I didn't interpret what he wrote the way you did, though I > suppose I can see how you took it the way you did. > > My own opinion is that a defect in the standard doesn't require us to > discard common sense. I wouldn't hesitate to rely on the behavior of > `obj.m = 42;`, and I don't think James would either. > > -- > 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" Both Jonathan Rhodes and Schrödinger had their public farts and their pickles. But one played it cool and didn't do anything too outrageous that could not be obfuscated with a larger scandal. This forum is a leaking porta potty. This is undoubtedly an amusement of mine. I'm getting more posts hidden then show. I'm guessing the Animal abuser Paul F. Riddle Mac cultist is in its brain damage mode again. Drives the trolls crazy when they do not get attention. These posts are clearly at most partially automated, they are made by Animal abuser Paul F. Riddle who is a glue sniffing pervert with a sick agenda who has way too much time on his hands. -- Do not click this link!!! https://groups.google.com/forum/#!topic/alt.os.linux/BVpdH5KOc6s https://goo.gl/Fho5Nq Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-13 00:27 -0700 |
| Message-ID | <b3307207-392e-42e0-bb8a-8094767534b1@googlegroups.com> |
| In reply to | #129109 |
On Thursday, April 12, 2018 at 2:43:54 PM UTC-7, supe...@casperkitty.com wrote: > On Thursday, April 12, 2018 at 4:26:24 PM UTC-5, Keith Thompson wrote: > > > The notion that > > > such code should be considered unusable in "Standard C" because it uses an > > > lvalue of type "int" to access an object of type "struct foo" would be > > > absurd if one intends "Standard C" to be a useful language. > > > > Yes, that would be absurd, which is why (unless I've missed something) > > nobody here has made such a claim. > > Perhaps I misunderstood what you meant by > > > > I believe that the standard means what it actually says, even when what > > > it actually says doesn't mean what the committee intended it to mean. > > > When that is the case, I consider it a defect in the standard that needs > > > correcting, not a justification for twisting the meaning of the relevant > > > terms so that what it actually says ends up matching what it should have > > > said. > > If the Standard as written is meaningless, but a slight adjustment would > make it meaningful, are you saying that the Standard should have simply > been dismissed as meaningless, rather than used as the basis for something > that would be usable? > > I suppose in retrospect that might have eventually resulted in the > Committee writing something that could be useful as written, and avoided > the mess they've created by their failure to do so, but the defects in > the Standard wouldn't have caused any problem if compiler writers had > interpreted UB as an invitation to look at precedents in similar compilers, > rather than as an excuse to ignore them. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 It was me and "trolling" meant pointing out your inconsistencies: "He has lied about the war on Iraq. An illegal war. One that makes him a war criminal." - Snit A week later: "Right: I can not unequivocally state that Bush is a war criminal." - Snit The following week: "Bush is a war criminal". - Snit Just mass confusion from you: "Ok... Morally he is a war criminal. Legally, it has not been decided." - Snit This is really no different than what owl just complained about in this thread, your obvious confusion is causing you to make inconsistent statements. Maybe someday, when you lay off the meds long enough, your brain may come back... but I doubt it ;) -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVRYkSAAoJEC03b6bOr/+dr7IP/1Z9K8QBaI8IfhOHC80aLVVu TLB1Cioe7BOV6KJ7kDCwS3llCPvgBLiLOMieFQDxMu6TogniEJzuZVBQL8Ivl4AT hbr36JSgN1GYnUHR3W14tficgW2Y/An7oYv3jYW5WjRM3hBUBq1A5FKtOUGObygp g1cNoNz2nd5rbEhfEApK9HBY3GsZjKUr120dp9bx8dKjSEklPXMWH7Qi2poOLATg RFemLCwUTn5+FwOIclI1Sxqi1CC3oYSS9nhk+Y1kdH89kfF7n91k2T7Bj00166qH erkm7wC07bnfq02omMqnjvaSc4BnRDtFLuZwa4U8zo+QtqRsfr6skT2Dbacj9rSH 1qVVsGqI6etckD3NLnOclstu+l/hRfGT7iQR8+YTRl+aZ9p/CJGc1XCCUlB5DyT4 Ffk2JRIwbHCbwcIxSdJOGxmzFpScTfh/pHUVmhuI1XXxprnxZoNCBI6PKhCB3lNh h0VbWixAwlQy5GOmqlH3W12eX0jQDdpEoPZbDYuAwugrvPEQXkho3Fsg1Hc1xkYW 6Qag+8MPxEOzIesTmMlQTLR6FLo38uoG9XCS0ykemcCQaWTdJ8sWm51cF9aRz1w7 lKVEiulNtiQIKKnMXhMgJPt0avNxZUZDEo6erzyoCaBmqisv6C4aqQWRNMnElFWJ uVezR4u0/sYGCYa1InhL =fdE9 -----END PGP SIGNATURE----- -- Best CMS Solution of 2017 http://www.5z8.info/--INITIATE-CREDIT-CARD-XFER--_k7s1jt_inject_worm https://prescottareapsychopaths.wordpress.com/shawn-ulman-psychopath Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2018-04-13 07:19 -0700 |
| Message-ID | <390abe70-908f-4f19-b6f8-84ec38d3ea90@googlegroups.com> |
| In reply to | #129102 |
On Thursday, April 12, 2018 at 10:54:43 AM UTC-4, supe...@casperkitty.com wrote:
> On Thursday, April 12, 2018 at 8:45:55 AM UTC-5, james...@verizon.net wrote:
> > I believe that the standard means what it actually says, even when what
> > it actually says doesn't mean what the committee intended it to mean.
> > When that is the case, I consider it a defect in the standard that needs
> > correcting, not a justification for twisting the meaning of the relevant
> > terms so that what it actually says ends up matching what it should have
> > said. In particular, if the standard uses a term inconsistently, what
> > that usually means is that at least one of those uses was incorrect, not
> > that the term was intended to simultaneously have multiple incompatible
> > meanings, with the correct one to be divined from context.
>
> If the Standard fails to define the behavior of a construct, but every
> reasonable person would agree upon what should be a defined behavior,
> should programmers regard the construct as unusable unless or until the
> authors of the Standard get around to actually defining it?
No, they should consider it unusable until somebody (not
necessarily the C committee) defines what it should do in EVERY
context where it needs to have defined behavior. If nobody has
actually defined the behavior yet, it doesn't matter how many
people agree that there's only one reasonable way to define it.
If nobody has defined it yet, you can't count on any compiler
having implemented it in that way.
If, for example, your code only needs to work on the MSVC++
compiler,the key thing that needs to be known is what definition,
if any, MSVC++ provides for the behavior. It's completely
irrelevant whether it's reasonable behavior in the eye of anyone
- the only thing that matters is whether it's defined, by a
suitable authority. Even if almost everyone agrees that a
particular behavior is the only reasonable one, if the actual
behavior defined by the compilers you need your code to be
compatible with is unreasonable, you need to write your code to
not only permit, but rely upon, that unreasonable behavior.
Realistically, if it is truly unreasonable behavior, you can
expect a future correction to more reasonable behavior - but
until the correction has occurred, you need to write your code
to deal with the language as actually implemented, not as you
would want it to be implemented.
> Remember that the purpose of the Standard was not to define a new language,
> but to codify an existing one,
That was never the sole goal of the standard, just one among
many other goals, and I've seen the text you've misinterpreted as
promoting that one goal to topmost status, overriding all other
possible goals. That's not the way the Committee feels about that
clause.
> ... and the authors focused on places where
> different implementations did things differently. Given something like:
>
> struct foo {int x, y;} s;
> ...
> s.y = 3;
>
> there was never any doubt about how the assignment should behave on
> platforms where "struct foo" would have no padding, and even on platforms
> where it does have padding the only question would be whether an
> implementation would be required to avoid disturbing it. The notion that
> such code should be considered unusable in "Standard C" because it uses an
> lvalue of type "int" to access an object of type "struct foo" would be
> absurd if one intends "Standard C" to be a useful language.
I believe that the standard, as currently written, incorrectly
and unintentionally specifies that the behavior of such code is
undefined. Because I believe it to be incorrect, unintentional,
and that essentially no existing implementations of C actually
take advantage of that fact (because they don't want to be
executed by mobs of angry users), I do not consider this fact to
be sufficient justification for avoiding writing such code. I
would like to see the wording improved so that it means what it
was intended to mean. However, since the problem was first
pointed out at least two revisions ago, I'm not exactly holding
my breath while waiting for an improvement.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-16 08:52 -0700 |
| Message-ID | <64746e6c-0c23-47a6-a5d4-d15a33db4aed@googlegroups.com> |
| In reply to | #129147 |
On Friday, April 13, 2018 at 9:20:07 AM UTC-5, james...@verizon.net wrote:
> On Thursday, April 12, 2018 at 10:54:43 AM UTC-4, supe...@casperkitty.com wrote:
> > If the Standard fails to define the behavior of a construct, but every
> > reasonable person would agree upon what should be a defined behavior,
> > should programmers regard the construct as unusable unless or until the
> > authors of the Standard get around to actually defining it?
>
> No, they should consider it unusable until somebody (not
> necessarily the C committee) defines what it should do in EVERY
> context where it needs to have defined behavior. If nobody has
> actually defined the behavior yet, it doesn't matter how many
> people agree that there's only one reasonable way to define it.
> If nobody has defined it yet, you can't count on any compiler
> having implemented it in that way.
What if *practically everyone* had defined it the same way, and the only
thing in the Standard that would prevent it from being defined was an
explicit statement that it wasn't?
> > Remember that the purpose of the Standard was not to define a new language,
> > but to codify an existing one,
>
> That was never the sole goal of the standard, just one among
> many other goals, and I've seen the text you've misinterpreted as
> promoting that one goal to topmost status, overriding all other
> possible goals. That's not the way the Committee feels about that
> clause.
A language called "C", as well as a variety of dialects, already existed.
If the Committee's goal was to create a new language rather than describe
the existing one, they should have picked some other name.
> > ... and the authors focused on places where
> > different implementations did things differently. Given something like:
> >
> > struct foo {int x, y;} s;
> > ...
> > s.y = 3;
> >
> > there was never any doubt about how the assignment should behave on
> > platforms where "struct foo" would have no padding, and even on platforms
> > where it does have padding the only question would be whether an
> > implementation would be required to avoid disturbing it. The notion that
> > such code should be considered unusable in "Standard C" because it uses an
> > lvalue of type "int" to access an object of type "struct foo" would be
> > absurd if one intends "Standard C" to be a useful language.
>
> I believe that the standard, as currently written, incorrectly
> and unintentionally specifies that the behavior of such code is
> undefined. Because I believe it to be incorrect, unintentional,
> and that essentially no existing implementations of C actually
> take advantage of that fact (because they don't want to be
> executed by mobs of angry users), I do not consider this fact to
> be sufficient justification for avoiding writing such code.
Is there anything in the Standard that would suggest that given:
struct s1 { int x; ... };
struct s2 { int x; ... };
union u { struct s1 v1; struct s2 v2; } uarr[10];
int i = ...;
there would be any cases where "uarr[i].v1.x = 23" would be defined but
{
struct s1 *p1 = &uarr[i].v1;
p1->x++;
}
would not have the same defined behavior? A compiler might not be expected
to recognize forever and everywhere that uarr[i] and p1 might access the
same storage, but when the Standard was written I don't think anyone would
have doubted that any quality compiler should recognize that the write to
p1->x above might affect, or have been affected by, operations using other
members of uarr.
> I
> would like to see the wording improved so that it means what it
> was intended to mean. However, since the problem was first
> pointed out at least two revisions ago, I'm not exactly holding
> my breath while waiting for an improvement.
The nonsensical rationale given in DR028 threw clean sensible semantics
out the window, and C99's botched attempt to add "Effective Type" rules to
fix the nonsense introduced by DR028 added extra complications and
impediments to useful optimizations, while doing nothing to resolve a
simple and fundamental problem. Perhaps having C11 say nothing more on the
issue was better than giving the Standard a chance to botch things up even
worse.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2018-04-16 10:28 -0700 |
| Message-ID | <a4ad0855-8098-4bb3-b499-ca1ca457df99@googlegroups.com> |
| In reply to | #129265 |
On Monday, April 16, 2018 at 11:53:02 AM UTC-4, supe...@casperkitty.com wrote: > On Friday, April 13, 2018 at 9:20:07 AM UTC-5, james...@verizon.net wrote: > > On Thursday, April 12, 2018 at 10:54:43 AM UTC-4, supe...@casperkitty.com wrote: > > > If the Standard fails to define the behavior of a construct, but every > > > reasonable person would agree upon what should be a defined behavior, > > > should programmers regard the construct as unusable unless or until the > > > authors of the Standard get around to actually defining it? > > > > No, they should consider it unusable until somebody (not > > necessarily the C committee) defines what it should do in EVERY > > context where it needs to have defined behavior. If nobody has > > actually defined the behavior yet, it doesn't matter how many > > people agree that there's only one reasonable way to define it. > > If nobody has defined it yet, you can't count on any compiler > > having implemented it in that way. > > What if *practically everyone* had defined it the same way, and the only > thing in the Standard that would prevent it from being defined was an > explicit statement that it wasn't? You misunderstand a key point: if a construct has behavior that is undefined according to the C standard, regardless of which of the three permitted methods is used to specify that fact (4p2), it means only that "... this international standard imposes no requirements" (3.4.3p1). The fact that the C standard labels a construct as having undefined behavior has absolutely no power to prevent anyone other than the C standard from defining the behavior; a fully conforming implementation can do just that, and in fact one of the common justifications for giving a construct "undefined behavior" is to leave room for implementations to provide their own definitions for the behavior that the C standard refuses to define. It is possible, indeed likely, that implementations that choose to provide such a definition will provide incompatible definitions - if that weren't the case, the committee would probably have chosen to define the behavior itself. If you want to avoid worrying about such incompatibilities, don't write such code - discouraging the writing of such code is one of the other main motivations for making the behavior undefined. And unless someone has actually chosen to define the behavior (which someone would almost certainly have done if *practically everyone* was in agreement), you'd have to be insane to write code that relies upon the guarantee that no one has provided. If everyone is in agreement about the behavior should be, but no one has yet provided such a definition, that implies that no one has yet bothered to do the work needed to guarantee implementation of that behavior. > > > Remember that the purpose of the Standard was not to define a new language, > > > but to codify an existing one, > > > > That was never the sole goal of the standard, just one among > > many other goals, and I've seen the text you've misinterpreted as > > promoting that one goal to topmost status, overriding all other > > possible goals. That's not the way the Committee feels about that > > clause. > > A language called "C", as well as a variety of dialects, already existed. > If the Committee's goal was to create a new language rather than describe > the existing one, they should have picked some other name. That would have defeated the purpose of the standard, which was to tame the wild variety of existing implementations of C by imposing some requirements that all of them would have to satisfy if they wished to qualify as conforming implementations (they are free not to care about that issue). Those requirements define a new family of closely related languages, very similar to the original family, but specified more precisely and consistently, with some important improvements, and in accordance with ANSI (and later, ISO) requirements. The new family of languages retained the same name as the original, for precisely the same reason (and possibly with better justification) that a 2018 Honda Fit uses the same name as the 2001 Honda Fit. The use of "C89" (ANSI) or "C90" (ISO) rather than "K&R C" was was sufficient to distinguish them, if necessary; there were not sufficient differences (your misconceptions about K&R C to the contrary notwithstanding) to justify giving it a new name. ... > Is there anything in the Standard that would suggest that given: I've learned that any question you pose in that format isn't worth answering.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-16 13:58 -0700 |
| Message-ID | <83589df8-fa61-4ffb-8fef-09ab50c8fcf4@googlegroups.com> |
| In reply to | #129277 |
On Monday, April 16, 2018 at 12:28:46 PM UTC-5, james...@verizon.net wrote:
> On Monday, April 16, 2018 at 11:53:02 AM UTC-4, supe...@casperkitty.com wrote:
> > What if *practically everyone* had defined it the same way, and the only
> > thing in the Standard that would prevent it from being defined was an
> > explicit statement that it wasn't?
>
> You misunderstand a key point: if a construct has behavior that is
> undefined according to the C standard, regardless of which of the three
> permitted methods is used to specify that fact (4p2), it means only that
> "... this international standard imposes no requirements" (3.4.3p1). The
> fact that the C standard labels a construct as having undefined behavior
> has absolutely no power to prevent anyone other than the C standard from
> defining the behavior; a fully conforming implementation can do just
> that, and in fact one of the common justifications for giving a
> construct "undefined behavior" is to leave room for implementations to
> provide their own definitions for the behavior that the C standard
> refuses to define.
Labeling constructs as Undefined Behavior means that they are unusable in
Strictly Conforming programs, and consequently reduces the range of tasks
that can be performed cleanly and efficiently with such programs. Since
the term "Conforming C Program" is defined so broadly as to be just about
meaningless, there really isn't any usefully-defined category of C programs
other than Strictly Conforming, so requiring such programs to jump through
hoops to do anything with structures seems like a bad idea.
> It is possible, indeed likely, that implementations
> that choose to provide such a definition will provide incompatible
> definitions - if that weren't the case, the committee would probably
> have chosen to define the behavior itself. If you want to avoid worrying
> about such incompatibilities, don't write such code - discouraging the
> writing of such code is one of the other main motivations for making the
> behavior undefined.
The authors of the Standard were intending to discourage programs from
making use of structures and unions with non-character members?
> And unless someone has actually chosen to define the behavior (which
> someone would almost certainly have done if *practically everyone* was
> in agreement), you'd have to be insane to write code that relies upon
> the guarantee that no one has provided. If everyone is in agreement
> about the behavior should be, but no one has yet provided such a
> definition, that implies that no one has yet bothered to do the work
> needed to guarantee implementation of that behavior.
Before the ratification of C89, just about anything that could reasonably
be called a C compiler defined the behavior of the struct and union member
access operators the same way, and nothing anywhere suggested that such
behavior should be limited for character types. Every version of the C
Standard has included rules which, as written, "undefines" the behavior of
nearly all code that uses members of non-character type.
How many implementations have you see that explicitly specify that they do
not restrict the use of struct-member and union-member operators to
character types? Would you guess that even 1% do so? How many do
restrict the use of such operators to character types? Even 1%?
Unless at least 25% of implementations either document the ability to use
non-character types with member-access operators, or at least 25% limit the
use of such operators to character types, at least 56% of implementations
must provide the ability to use non-character types without documenting it.
> > A language called "C", as well as a variety of dialects, already existed.
> > If the Committee's goal was to create a new language rather than describe
> > the existing one, they should have picked some other name.
>
> That would have defeated the purpose of the standard, which was to tame
> the wild variety of existing implementations of C by imposing some
> requirements that all of them would have to satisfy if they wished to
> qualify as conforming implementations (they are free not to care about
> that issue). Those requirements define a new family of closely related
> languages, very similar to the original family, but specified more
> precisely and consistently, with some important improvements, and in
> accordance with ANSI (and later, ISO) requirements. The new family of
> languages retained the same name as the original, for precisely the same
> reason (and possibly with better justification) that a 2018 Honda Fit
> uses the same name as the 2001 Honda Fit.
How do you see the purpose of the Standard?
IMHO, the purpose of a good language standard should be to define at least
one category P of programs and at least one category of implementations I
such that:
1. The range of tasks that can be done by programs in category P is as
wide as practical.
2. The range of platforms that can support implementations in category
I is as wide as practical.
3. Every implementation in category I documents a set of environmental
requirements and failure modes; when given *any* program in category
P, it will never do anything other than behave as indicated by the
Standard or fail *in one of the expressly-documented ways*.
Note that set I would include an "implementation" that never did anything
other than output "Sorry" [and documented that as its failure mode], and
set P would include a "program" that simply said "#error sorry" [since
any implementation in set I would be required to fail because of the
directive unless it failed for some other reason first], but the two sets
would exclude many other things that would qualify as "conforming" under
today's standards.
While it may be useful to also recognize categories of programs P' and
implementations I' such that most programs in P' would be successfully
processed by implementations in I', and quality implementations should
attempt to support as many programs in P' as practical, I would regard
those as far less important than having a category of programs whose
behavior would always, at worst, be constrained to an Unspecified choice
from among Implementation-Defined possibilities.
> The use of "C89" (ANSI) or "C90" (ISO) rather than "K&R C" was was
> sufficient to distinguish them, if necessary; there were not sufficient
> differences (your misconceptions about K&R C to the contrary
> notwithstanding) to justify giving it a new name.
>
> ...
> > Is there anything in the Standard that would suggest that given:
>
> I've learned that any question you pose in that format isn't worth
> answering.
Let me rephrase it: how should one distinguish between cases where the
Standard says a construct is undefined, but that's sufficiently obviously
a mistake that programmers should feel safe using it anyway, from those
which programmers must avoid because compiler writers will interpret them
as "optimization" opportunities.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2018-04-16 14:52 -0700 |
| Message-ID | <b9ba615a-a637-4c93-bd44-3f42d2578b2c@googlegroups.com> |
| In reply to | #129289 |
On Monday, April 16, 2018 at 4:58:39 PM UTC-4, supe...@casperkitty.com wrote: > On Monday, April 16, 2018 at 12:28:46 PM UTC-5, james...@verizon.net wrote: > > On Monday, April 16, 2018 at 11:53:02 AM UTC-4, supe...@casperkitty.com ... > > You misunderstand a key point: if a construct has behavior that is > > undefined according to the C standard, regardless of which of the three > > permitted methods is used to specify that fact (4p2), it means only that > > "... this international standard imposes no requirements" (3.4.3p1). The > > fact that the C standard labels a construct as having undefined behavior > > has absolutely no power to prevent anyone other than the C standard from > > defining the behavior; a fully conforming implementation can do just > > that, and in fact one of the common justifications for giving a > > construct "undefined behavior" is to leave room for implementations to > > provide their own definitions for the behavior that the C standard > > refuses to define. > > Labeling constructs as Undefined Behavior means that they are unusable in > Strictly Conforming programs, Yes, and not all C code needs to be strictly conforming. In fact, most C code fails to be strictly conforming, and this is not considered a problem by the committee. > ... and consequently reduces the range of tasks > that can be performed cleanly and efficiently with such programs. Since Not really - the things that are labelled "undefined behavior" are generally things for which no standard-defined behavior would be cleanly and efficiently implementable on all platforms. By allowing implementations to provide their own definitions, code can be written in C which is clean and efficient for one platform, despite the fact that it won't work on another platform. > > It is possible, indeed likely, that implementations > > that choose to provide such a definition will provide incompatible > > definitions - if that weren't the case, the committee would probably > > have chosen to define the behavior itself. If you want to avoid worrying > > about such incompatibilities, don't write such code - discouraging the > > writing of such code is one of the other main motivations for making the > > behavior undefined. > > The authors of the Standard were intending to discourage programs from > making use of structures and unions with non-character members? No - as I indicated farther up-thread, it is my contention that this part of the wording of the standard is defective by reason of not clearly conveying the intentions of the committee. Is that really so hard to believe? Any document of any significant size contains such defects. ... > IMHO, the purpose of a good language standard should be to define at least > one category P of programs and at least one category of implementations I > such that: > > 1. The range of tasks that can be done by programs in category P is as > wide as practical. > > 2. The range of platforms that can support implementations in category > I is as wide as practical. > > 3. Every implementation in category I documents a set of environmental > requirements and failure modes; when given *any* program in category > P, it will never do anything other than behave as indicated by the > Standard or fail *in one of the expressly-documented ways*. The C standard is written with a different set of priorities. A top priority is for it to be possible for C to be efficiently implemented on as wide a variety of platforms as possible. That priority is so high that the committee prefers to deliberately allow for the possibility that code written to use a fully conforming implementation of C on one platform as efficiently as possible might not be efficient, or even compileable, on a fully conforming implementation of C targeting a different platform. If compilability is more important to you, avoid using the problematic constructs (those with undefined behavior) - if you want efficiency, feel free to use those constructs, but accept that your code won't work on all platforms. ... > Let me rephrase it: how should one distinguish between cases where the > Standard says a construct is undefined, but that's sufficiently obviously > a mistake that programmers should feel safe using it anyway, from those > which programmers must avoid because compiler writers will interpret them > as "optimization" opportunities. That requires a fair amount of awareness of and sympathy with the goals of the committee, something that I doubt you'll ever have, since your goals are so different. To me, it seems patently obvious that the current wording gives undefined behavior to such accesses, and that it would be ridiculous for that to be the case. I believe that it was intended that a structure's value be modifiable by (recursively) the use of an lvalue that has the type of one of the struct's members, and which refers to a member of the structure of that type, but only so long as the modification to the struct's value are restricted to a corresponding change of that member's value. The easiest way to correct the wording to allow that might not be to add it as another item on the list in 6.5p7, but to modify the definitions of various terms to make that result come out automatically. Tim seems to have inferred the undocumented existence of such modified definitions in the existing standard, a conclusion that is enabled by a belief that the relevant terms are used inconsistently, and that he's permitted to assume such inconsistencies wherever he needs to in order for the standard to make sense. I say "seems", because I can't quite manage to choose questions to ask that he feels obligated to answer as asked, which would enable me to understand precisely what he's thinking.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-16 16:22 -0700 |
| Message-ID | <646ca446-53a3-4006-a476-6f52caacd8c9@googlegroups.com> |
| In reply to | #129290 |
On Monday, April 16, 2018 at 4:53:09 PM UTC-5, james...@verizon.net wrote: > On Monday, April 16, 2018 at 4:58:39 PM UTC-4, supe...@casperkitty.com wrote: > > Labeling constructs as Undefined Behavior means that they are unusable in > > Strictly Conforming programs, > > Yes, and not all C code needs to be strictly conforming. In fact, most > C code fails to be strictly conforming, and this is not considered a > problem by the committee. The problem is that the Standard doesn't offer any other concept of what it would mean for a program to be written in "standard" C. > > ... and consequently reduces the range of tasks > > that can be performed cleanly and efficiently with such programs. Since > > Not really - the things that are labelled "undefined behavior" are > generally things for which no standard-defined behavior would be cleanly > and efficiently implementable on all platforms. By allowing > implementations to provide their own definitions, code can be written in > C which is clean and efficient for one platform, despite the fact that > it won't work on another platform. That is *generally* true, but there are some notable exceptions such as 6.5p7. That paragraph primarily affects programs whose meaning would otherwise be unambiguously implied by implementations' specified storage formats. > > The authors of the Standard were intending to discourage programs from > > making use of structures and unions with non-character members? > > No - as I indicated farther up-thread, it is my contention that this > part of the wording of the standard is defective by reason of not > clearly conveying the intentions of the committee. Is that really so > hard to believe? Any document of any significant size contains such > defects. How often do such defects persist through decades of revisions? > > IMHO, the purpose of a good language standard should be to define at least > > one category P of programs and at least one category of implementations I > > such that: > > > > 1. The range of tasks that can be done by programs in category P is as > > wide as practical. > > > > 2. The range of platforms that can support implementations in category > > I is as wide as practical. > > > > 3. Every implementation in category I documents a set of environmental > > requirements and failure modes; when given *any* program in category > > P, it will never do anything other than behave as indicated by the > > Standard or fail *in one of the expressly-documented ways*. > > The C standard is written with a different set of priorities. A top > priority is for it to be possible for C to be efficiently implemented on > as wide a variety of platforms as possible. What platforms could support the C Standard, but could not practically uphold the guarantees specified above? While some programmers might opt for a "hope for the best" mode that behaves in arbitrary fashion in case of stack overflow than one which is guaranteed to trap in constrained fashion if there's not enough stack to continue processing normally, allowing implementations to reject programs they can't support would increase the range of platforms that could be used to run a useful number of C programs in Standard-defined fashion. > That priority is so high that > the committee prefers to deliberately allow for the possibility that code > written to use a fully conforming implementation of C on one platform as > efficiently as possible might not be efficient, or even compileable, on a > fully conforming implementation of C targeting a different platform. If > compilability is more important to you, avoid using the problematic > constructs (those with undefined behavior) - if you want efficiency, > feel free to use those constructs, but accept that your code won't work > on all platforms. Under my proposal, any implementation would be allowed to reject any program. The difference vs the standard is that implementations would be *required* to fail in defined fashion when given a program whose requirements they could not satisfy. To put it another way, what's important is to have a large range of programs whose behavior is defined by the Standard as either "do X or fail in Implementation Defined fashion"; the fact that 25% of implementations would be unable to support a behavior (and would thus be required to fail when given a program that needs it) should not be an obstacle to making the behavior usable on the other 75%. > > Let me rephrase it: how should one distinguish between cases where the > > Standard says a construct is undefined, but that's sufficiently obviously > > a mistake that programmers should feel safe using it anyway, from those > > which programmers must avoid because compiler writers will interpret them > > as "optimization" opportunities. > > That requires a fair amount of awareness of and sympathy with the goals > of the committee, something that I doubt you'll ever have, since your > goals are so different. What are the goals of the Committee? Does it actually have a coherent goal, or do different members have different contradictory goals that prevent the formation of a coherent one? > To me, it seems patently obvious that the current wording gives > undefined behavior to such accesses, and that it would be ridiculous for > that to be the case. I believe that it was intended that a structure's > value be modifiable by (recursively) the use of an lvalue that has the > type of one of the struct's members, and which refers to a member of the > structure of that type, but only so long as the modification to the > struct's value are restricted to a corresponding change of that member's > value. What is the intended purpose of having the address-of operator yield a pointer of an aggregate's member type when applied to an lvalue of the form aggregate.member or aggregatePtr->member? Is it to yield a pointer that may be used to access an object of that type in at least some circumstances? If so, in what circumstances? > The easiest way to correct the wording to allow that might not be to add > it as another item on the list in 6.5p7, but to modify the definitions > of various terms to make that result come out automatically. Tim seems > to have inferred the undocumented existence of such modified definitions > in the existing standard, a conclusion that is enabled by a belief that > the relevant terms are used inconsistently, and that he's permitted to > assume such inconsistencies wherever he needs to in order for the > standard to make sense. I say "seems", because I can't quite manage to > choose questions to ask that he feels obligated to answer as asked, > which would enable me to understand precisely what he's thinking. I've adopted a similar approach, but requiring that all lvalues used to access a region of storage within a particular execution of a function or loop must "use" an lvalue of the same type, and extending the concept of "use" to recognize that certain actions upon derived lvalues "use" the parent.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-04-16 21:51 -0400 |
| Message-ID | <uqcBC.238$o43.209@fx33.iad> |
| In reply to | #129294 |
On 4/16/18 7:22 PM, supercat@casperkitty.com wrote: > That is *generally* true, but there are some notable exceptions such as > 6.5p7. That paragraph primarily affects programs whose meaning would > otherwise be unambiguously implied by implementations' specified storage > formats. An you don't seem to understand that what this paragraph says (as supported by the footnote) that this limitation defines what the Standard enforces on an implementation. NOTHING in this statement says that an implementation can't define other conditions or methods of accesses and how they behave. Yes, this does say that, absent promises by the implementation, that a naive expectation of what seems 'natural' for a processor will behave the way you want if you don't follow those rules. Every implementation that I know of allows for ways to tell the compiler "I'm playing tricks here, please act 'dumb' and do just what I am saying". Yes, this says you DO need to read and understand the documentation (and if still not sure ASK the implementer) to do this sort of trick.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-16 19:42 -0700 |
| Message-ID | <ln8t9mmu4d.fsf@kst-u.example.com> |
| In reply to | #129298 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 4/16/18 7:22 PM, supercat@casperkitty.com wrote:
>> That is *generally* true, but there are some notable exceptions such as
>> 6.5p7. That paragraph primarily affects programs whose meaning would
>> otherwise be unambiguously implied by implementations' specified storage
>> formats.
>
> An you don't seem to understand that what this paragraph says (as
> supported by the footnote) that this limitation defines what the
> Standard enforces on an implementation. NOTHING in this statement says
> that an implementation can't define other conditions or methods of
> accesses and how they behave.
>
> Yes, this does say that, absent promises by the implementation, that a
> naive expectation of what seems 'natural' for a processor will behave
> the way you want if you don't follow those rules. Every implementation
> that I know of allows for ways to tell the compiler "I'm playing tricks
> here, please act 'dumb' and do just what I am saying".
>
> Yes, this says you DO need to read and understand the documentation (and
> if still not sure ASK the implementer) to do this sort of trick.
Except that *if* I'm reading 6.5p7 correctly (as it's written, as
opposed to as it was almost certainly intended), then the behavior
of `obj.m = 42;` is explicitly undefined, because it accesses the
struct object `obj` by the value `obj.m`, which has type int.
I have no doubt that the intent was for `obj.m = 42;` to be well
defined, modifying the value of obj.m and therefore the value of obj.
The modification of obj is not (intended to be) undefined behavior
that every implementation happens to sensibly implement in the
same way. It's behavior that is intended to be well defined, with
no wiggle room, but the standard failed to specify it correctly.
(Assume if you like that "obj" is a struct whose only member is
"m", of type int, that obj has no padding bytes, and that int has
no padding bits or trap representations.)
(Yes, Tim, I'm still planning to respond to your earlier posts.)
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-04-16 21:30 -0700 |
| Message-ID | <kfnk1t68nez.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #129299 |
Keith Thompson <kst-u@mib.org> writes: > (Yes, Tim, I'm still planning to respond to your earlier posts.) Thank you, I smiled when I saw this. :)
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-04-17 07:01 -0400 |
| Message-ID | <TtkBC.1448$LR2.1099@fx41.iad> |
| In reply to | #129299 |
On 4/16/18 10:42 PM, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> On 4/16/18 7:22 PM, supercat@casperkitty.com wrote: >>> That is *generally* true, but there are some notable exceptions such as >>> 6.5p7. That paragraph primarily affects programs whose meaning would >>> otherwise be unambiguously implied by implementations' specified storage >>> formats. >> >> An you don't seem to understand that what this paragraph says (as >> supported by the footnote) that this limitation defines what the >> Standard enforces on an implementation. NOTHING in this statement says >> that an implementation can't define other conditions or methods of >> accesses and how they behave. >> >> Yes, this does say that, absent promises by the implementation, that a >> naive expectation of what seems 'natural' for a processor will behave >> the way you want if you don't follow those rules. Every implementation >> that I know of allows for ways to tell the compiler "I'm playing tricks >> here, please act 'dumb' and do just what I am saying". >> >> Yes, this says you DO need to read and understand the documentation (and >> if still not sure ASK the implementer) to do this sort of trick. > > Except that *if* I'm reading 6.5p7 correctly (as it's written, as > opposed to as it was almost certainly intended), then the behavior > of `obj.m = 42;` is explicitly undefined, because it accesses the > struct object `obj` by the value `obj.m`, which has type int. > > I have no doubt that the intent was for `obj.m = 42;` to be well > defined, modifying the value of obj.m and therefore the value of obj. > The modification of obj is not (intended to be) undefined behavior > that every implementation happens to sensibly implement in the > same way. It's behavior that is intended to be well defined, with > no wiggle room, but the standard failed to specify it correctly. > (Assume if you like that "obj" is a struct whose only member is > "m", of type int, that obj has no padding bytes, and that int has > no padding bits or trap representations.) > > (Yes, Tim, I'm still planning to respond to your earlier posts.) > That may be a defect in the Standard, or maybe they thought that it was obvious that an assignment to obj.m will (possible) change the value of obj, but isn't considered (for this purpose) an access of obj, but only of its sub-object.
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web