Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #71436 > unrolled thread
| Started by | supercat@casperkitty.com |
|---|---|
| First post | 2015-09-29 09:49 -0700 |
| Last post | 2015-10-04 22:16 -0700 |
| Articles | 20 on this page of 172 — 16 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-09-29 09:49 -0700
Re: C pointer semantics with dynamically allocated struct wssimms@gmail.com - 2015-09-30 21:18 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-01 09:35 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-01 09:41 -0700
Re: C pointer semantics with dynamically allocated struct gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-01 18:34 +0000
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-01 12:02 -0700
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-02 13:03 +0000
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-02 06:20 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 16:07 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-02 08:46 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 17:28 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-02 10:30 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 20:32 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-02 12:58 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 22:06 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 09:31 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-03 14:31 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 09:27 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-03 20:36 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 13:00 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-03 23:37 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 17:07 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-03 17:42 -0700
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 17:49 -0700
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-10-03 23:28 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-04 00:10 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-04 13:24 +0100
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-04 14:07 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-04 14:40 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-04 18:04 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-04 20:10 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-04 22:15 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-05 08:53 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-06 08:45 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-06 12:34 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-06 17:16 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-06 21:47 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-07 11:05 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-07 11:47 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-07 13:50 -0700
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-07 18:10 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-07 16:10 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-07 16:33 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 09:08 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 10:43 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 11:50 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 12:19 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-07 15:32 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-07 16:21 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 08:54 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 11:15 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 12:38 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 13:30 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 14:15 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 14:53 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-08 15:23 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-08 17:24 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-09 08:02 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-09 09:02 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-09 12:43 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-09 14:21 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-09 15:14 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-13 18:37 -0700
Re: C pointer semantics with dynamically allocated struct Martin Shobe <martin.shobe@yahoo.com> - 2015-10-07 20:56 -0500
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-07 19:41 -0700
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-07 23:15 -0400
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-14 10:05 +0000
Re: C pointer semantics with dynamically allocated struct Richard Heathfield <rjh@cpax.org.uk> - 2015-10-14 11:23 +0100
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-14 08:24 -0700
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-16 11:12 +0000
Re: C pointer semantics with dynamically allocated struct Gareth Owen <gwowen@gmail.com> - 2015-10-16 21:55 +0100
Re: C pointer semantics with dynamically allocated struct Les Cargill <lcargill99@comcast.com> - 2015-10-16 22:08 -0500
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-14 11:44 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-14 11:12 -0700
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-07 10:34 +0000
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-07 07:23 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-07 09:53 -0700
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-14 10:13 +0000
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-14 11:36 -0400
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-04 13:35 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-04 06:23 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-04 15:34 +0100
Re: C pointer semantics with dynamically allocated struct "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-04 08:07 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-04 14:42 +0000
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-04 15:37 +0000
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-05 00:33 +0100
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-14 10:20 +0000
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-14 13:55 +0100
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 22:06 -0700
Re: C pointer semantics with dynamically allocated struct raltbos@xs4all.nl (Richard Bos) - 2015-10-14 10:30 +0000
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-14 08:39 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-14 23:47 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-15 10:20 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-15 11:10 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-15 12:11 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-15 12:35 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-15 13:52 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-15 14:35 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-15 15:51 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 06:48 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-16 08:50 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 10:06 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-16 12:45 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 13:56 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-16 14:29 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 14:52 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-16 15:32 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 15:59 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-17 00:03 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-17 00:08 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 15:26 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-17 16:38 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-16 23:43 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-16 23:57 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 14:50 -0700
Re: C pointer semantics with dynamically allocated struct Ian Collins <ian-news@hotmail.com> - 2015-10-18 10:55 +1300
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-17 18:24 -0400
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-10-17 18:39 -0400
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-17 18:56 -0400
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 16:17 -0700
Re: C pointer semantics with dynamically allocated struct James Kuyper <jameskuyper@verizon.net> - 2015-10-18 11:46 -0400
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-10-17 19:44 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-17 16:48 -0700
Re: C pointer semantics with dynamically allocated struct Richard Heathfield <rjh@cpax.org.uk> - 2015-10-18 01:14 +0100
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-10-17 20:22 -0400
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-17 17:26 -0700
Re: C pointer semantics with dynamically allocated struct Richard Heathfield <rjh@cpax.org.uk> - 2015-10-18 01:44 +0100
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 20:09 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-18 11:24 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-19 04:42 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-19 16:24 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 02:20 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-19 19:53 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 09:41 +0000
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 19:53 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 16:07 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-17 14:55 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-18 04:28 +0000
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-15 12:49 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-15 12:26 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-15 12:48 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-17 08:21 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 22:23 -0700
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-02 09:10 -0700
Re: C pointer semantics with dynamically allocated struct Martin Shobe <martin.shobe@yahoo.com> - 2015-10-02 11:58 -0500
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-02 11:38 -0700
Re: C pointer semantics with dynamically allocated struct Martin Shobe <martin.shobe@yahoo.com> - 2015-10-05 09:36 -0500
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-12 09:47 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-13 02:51 +0000
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-12 23:45 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-15 13:54 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-16 01:07 +0000
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-19 15:33 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 19:21 +0100
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-02 12:10 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 21:24 +0100
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-02 14:32 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-02 23:43 +0100
Re: C pointer semantics with dynamically allocated struct supercat@casperkitty.com - 2015-10-02 16:49 -0700
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-03 02:01 +0100
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-03 00:38 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-02 16:10 -0700
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 21:54 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-05 08:19 -0700
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-02 15:16 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-02 22:52 +0000
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-03 00:48 -0700
Re: C pointer semantics with dynamically allocated struct glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-03 08:22 +0000
Re: C pointer semantics with dynamically allocated struct Keith Thompson <kst-u@mib.org> - 2015-10-03 12:05 -0700
Re: C pointer semantics with dynamically allocated struct Richard Damon <Richard@Damon-Family.org> - 2015-10-03 16:38 -0400
Re: C pointer semantics with dynamically allocated struct Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-03 00:00 +0100
Re: C pointer semantics with dynamically allocated struct Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 22:16 -0700
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-03 23:37 +0100 |
| Message-ID | <878u7jo9xi.fsf@bsb.me.uk> |
| In reply to | #71724 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Saturday, October 3, 2015 at 3:36:08 PM UTC-4, Ben Bacarisse wrote: >> So, to make this concrete, if the union access in question were >> undefined behaviour, a helpful debugging implementation of C would be >> permitted to make a note of the last member stored and use that to stop >> the program with a message "ERROR: accessing a different union member >> to the one last stored". This behaviour would be conforming. >> >> However, that is not permitted. The result of the access is not >> undefined by simply unspecified -- some value must be produced form the >> object's bits. > > Does this mean that it will read whatever was deposited there > previously by the prior write to another member? Or does it > mean that it's possible a prior write to another member, and > then a later read from another member, could produce results > which do not correspond to the bits written by the prior write? The footnote I quoted answers this question. >> In this case, the standard is being a bit coy because, whilst it is true >> that it does not formally impose any further requirements on the value >> chosen, a footnotes does explain what is to be expected: >> >> If the member used to read the contents of a union object is not the >> same as the member last used to store a value in the object, the >> appropriate part of the object representation of the value is >> reinterpreted as an object representation in the new type as described >> in 6.2.6 (a process sometimes called "type punning"). This might be a >> trap representation. >> >> Footnotes are described as being "for information only" rather than >> being a formally binding part of the language standard, but it's still >> information even if that is all it is. > > This seems to indicate it would always read back whatever was last > written -- up to min(sizeof(new read), sizeof(old write)). No, it indicates (or is supposed to indicate -- it may not have been successful in that endeavour) that sizeof(new read) bytes are read. Some (but maybe not all) of the these will have been written by the previous write. Some may not yet ever have been written to. > But another > post in this thread, by Keith I believe, said there is no hard-and-fast > requirement in C that union members overlay actual memory, and that > it's possible each member has its own allocated space, even though it's > in a union. That's odd. I don't recall that being said and I'd be very surprised if he did say it. C hides the details of where things are behind pointers, but all pointers to a union's different members must compare equal when converted to void *. > If true, it would seem to be undefined behavior, and not unspecified. Even it it were true, why would that make the behaviour undefined? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-03 17:07 -0700 |
| Message-ID | <1cb437ed-216b-439b-b892-60d5c8decf33@googlegroups.com> |
| In reply to | #71756 |
On Saturday, October 3, 2015 at 6:37:53 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> > But another
> > post in this thread, by Keith I believe, said there is no hard-and-fast
> > requirement in C that union members overlay actual memory, and that
> > it's possible each member has its own allocated space, even though it's
> > in a union.
>
> That's odd. I don't recall that being said and I'd be very surprised if
> he did say it. C hides the details of where things are behind pointers,
> but all pointers to a union's different members must compare equal when
> converted to void *.
It was in C90 he was talking about. I may have misunderstood what he's
saying here. To me it conveys that each member could be in its own
space since a read of one member does not guarantee access to the data
written mo a prior member's write:
https://groups.google.com/d/msg/comp.lang.c/qt1b1yZesws/iYAps--ADQAJ
"So C90, did not explicitly require the result of an access to
a union member to have anything to do with the value stored to
a different member; the behavior is implementation defined, so
in principle it could do just about anything. But I *think*
the intent was similar, perhaps identical, with C11 making the
wording clearer."
> > If true, it would seem to be undefined behavior, and not unspecified.
> Even it it were true, why would that make the behaviour undefined?
Perhaps this is me again using the term 'undefined behavior' to mean
what it means in English, and not what it means in the C standard...
Why?
Because you would not be able to rely on that feature across compilers.
Unions on one compiler might exhibit write-x, read-y behavior that
shows x's content as viewed through y's lens, but on another compile
it might show something else entirely that has nothing to do with x's
write.
Because there would be no way to guarantee that it would work, it would
be undefined behavior.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-03 17:42 -0700 |
| Message-ID | <3fc6919f-4b41-4eaf-8c4a-ca00ca97fce3@googlegroups.com> |
| In reply to | #71767 |
On Saturday, October 3, 2015 at 7:08:02 PM UTC-5, Rick C. Hodgin wrote: > Because there would be no way to guarantee that it would work, it would > be undefined behavior. The fact that one particular part of the Standard or part of a platform's documentation says that something is unspecified does not preclude the part of some other part of it specifying the behavior. If, however, part of the Standard states that some action invokes Undefined Behavior, that means that even other parts of the Standard which would otherwise define its behavior are no applicable, and modern philosophy seems to suggest that the fact that the Standard regards something is undefined should negate even parts of the compiler's own documentation which would otherwise describe the behavior.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-03 17:49 -0700 |
| Message-ID | <096d8d77-3b25-4073-b6f6-061a15554b4a@googlegroups.com> |
| In reply to | #71768 |
On Saturday, October 3, 2015 at 8:42:21 PM UTC-4, supe...@casperkitty.com wrote: > On Saturday, October 3, 2015 at 7:08:02 PM UTC-5, Rick C. Hodgin wrote: > > Because there would be no way to guarantee that it would work, it would > > be undefined behavior. > > The fact that one particular part of the Standard or part of a platform's > documentation says that something is unspecified does not preclude the > part of some other part of it specifying the behavior. If, however, part > of the Standard states that some action invokes Undefined Behavior, that > means that even other parts of the Standard which would otherwise define > its behavior are no applicable, and modern philosophy seems to suggest > that the fact that the Standard regards something is undefined should > negate even parts of the compiler's own documentation which would otherwise > describe the behavior. If the compiler supports extra-Standard behavior, then I don't see how that's an issue. So far as Standard-compliant compilers go it would be an issue, but so far as practical use, if the compiler guarantees it will work properly then it's an extension provided for by that compiler, one which likely has value, is desirable, and overrides limitations imposed upon software developers by the Standard. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-10-03 23:28 -0400 |
| Message-ID | <c11Qx.14631$5P5.7757@fx06.iad> |
| In reply to | #71768 |
On 10/3/15 8:42 PM, supercat@casperkitty.com wrote: > On Saturday, October 3, 2015 at 7:08:02 PM UTC-5, Rick C. Hodgin wrote: >> Because there would be no way to guarantee that it would work, it would >> be undefined behavior. > > The fact that one particular part of the Standard or part of a platform's > documentation says that something is unspecified does not preclude the > part of some other part of it specifying the behavior. If, however, part > of the Standard states that some action invokes Undefined Behavior, that > means that even other parts of the Standard which would otherwise define > its behavior are no applicable, and modern philosophy seems to suggest > that the fact that the Standard regards something is undefined should > negate even parts of the compiler's own documentation which would otherwise > describe the behavior. > Undefined behavior merely says that the C Standard does not define the behavior, other standards or documentation are allowed to (and often do). I am fairly sure that if one part of the C Standard calls a behavior undefined behavior, and another defines the behavior, then we have a defect in the standard, or a mis-reading of the standard.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-04 00:10 -0700 |
| Message-ID | <0a7549a1-b647-416a-b592-fd48f14690f9@googlegroups.com> |
| In reply to | #71779 |
On Saturday, October 3, 2015 at 10:28:16 PM UTC-5, Richard Damon wrote:
> I am fairly sure that if one part of the C Standard calls a behavior
> undefined behavior, and another defines the behavior, then we have a
> defect in the standard, or a mis-reading of the standard.
If one views memory as having no state beyond CHAR_BITS bits per byte, then
on a system where the indicated types are defined, there given the
declarations/initializations [assume the pointers themselves never
change]
uint8_t *buff = malloc(4);
uint16_t *hp = (uint16_t*)buff;
uint32_t *wp = (uint32_t*)buff;
the code "hp[0]=hp[1]=0;" would be required to set all four bytes of
"buff" to zero, and the invoking the code code "uint32_t x=*wp;" when
all four bytes of "buff" were zero would be required to set x to 0.
On the other hand, the Standard also says that writing those bytes
via the assignments to hp[0] and hp[1], and reading them using wp, would
invoke Undefined Behavior.
I would suggest that it is only the prohibition against writing as one type
and reading as another which would cause such behavior to be anything less
than fully defined; the effect of that prohibition is to trump the fact that
the behavior is defined elsewhere.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-04 13:24 +0100 |
| Message-ID | <8737xqom8h.fsf@bsb.me.uk> |
| In reply to | #71791 |
supercat@casperkitty.com writes: > On Saturday, October 3, 2015 at 10:28:16 PM UTC-5, Richard Damon wrote: >> I am fairly sure that if one part of the C Standard calls a behavior >> undefined behavior, and another defines the behavior, then we have a >> defect in the standard, or a mis-reading of the standard. > > If one views memory as having no state beyond CHAR_BITS bits per byte, then > on a system where the indicated types are defined, there given the > declarations/initializations [assume the pointers themselves never > change] > > uint8_t *buff = malloc(4); > uint16_t *hp = (uint16_t*)buff; > uint32_t *wp = (uint32_t*)buff; > > the code "hp[0]=hp[1]=0;" would be required to set all four bytes of > "buff" to zero, and the invoking the code code "uint32_t x=*wp;" when > all four bytes of "buff" were zero would be required to set x to 0. > > On the other hand, the Standard also says that writing those bytes > via the assignments to hp[0] and hp[1], and reading them using wp, would > invoke Undefined Behavior. > > I would suggest that it is only the prohibition against writing as one type > and reading as another which would cause such behavior to be anything less > than fully defined; the effect of that prohibition is to trump the fact that > the behavior is defined elsewhere. It's not a case of undefined trumping defined, it's that general rules about expression evaluation apply to all expressions. That's why they are discussed to early on. Having said that only certain accesses are permitted, there is no need to say it again when explaining the * operator or assignment. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-04 14:07 -0700 |
| Message-ID | <lnr3laxs05.fsf@kst-u.example.com> |
| In reply to | #71768 |
supercat@casperkitty.com writes:
[...]
> The fact that one particular part of the Standard or part of a platform's
> documentation says that something is unspecified does not preclude the
> part of some other part of it specifying the behavior.
I'd say that if that happens it's a defect in the Standard.
For example, N1570 6.3.2.3p6 says:
Any pointer type may be converted to an integer type. Except as
previously specified, the result is implementation-defined.
Without the phrase "Except as previously specified", that would be
incorrect. (If such defects do occur, the more specific statement
should probably be considered to override the more general one.)
> If, however, part
> of the Standard states that some action invokes Undefined Behavior, that
> means that even other parts of the Standard which would otherwise define
> its behavior are no applicable,
See above.
> and modern philosophy seems to suggest
> that the fact that the Standard regards something is undefined should
> negate even parts of the compiler's own documentation which would otherwise
> describe the behavior.
I disagree. A compiler is free to define behavior that is not
defined by the standard. It's still strictly "undefined behavior",
which means only that the standard doesn't define the behavior,
but the implementation would still presumably be bound by its own
documentation. (The standard doesn't require implementations to
follow their own documentation; that's outside its scope.)
--
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 | 2015-10-04 14:40 -0700 |
| Message-ID | <49f58313-f3f1-41d9-9201-0d532f6c0c05@googlegroups.com> |
| In reply to | #71851 |
On Sunday, October 4, 2015 at 4:07:14 PM UTC-5, Keith Thompson wrote: > I disagree. A compiler is free to define behavior that is not > defined by the standard. It's still strictly "undefined behavior", > which means only that the standard doesn't define the behavior, > but the implementation would still presumably be bound by its own > documentation. (The standard doesn't require implementations to > follow their own documentation; that's outside its scope.) If a behavior is categorized as Implementation-Defined, I would think that compliance with the Standard would mandate conformity with the documented behavior. If an implementation documents that signed integer reduction will be performed via two's-complement reduction, but (int16_t)65537 yielded 32767, I would regard that implementation as non-conformant even though such behavior would have been perfectly legitimate if the documentation had specified that out-of-range value would be "pegged" to the range of the resulting type. To not bind implementations' behavior to their documentation would render the term "implementation-defined" totally meaningless. Otherwise, in the particular case I mentioned, it would certainly be possible for an implementation to expressly state that pointer accesses will process variables in the indicated fashion without regard for whether the program accesses them in the fashion required by the Standard (and such guarantees are not even terribly uncommon), in the absence of language which would expressly disclaim the requirement I think UB-ness would dominate; at least that's how some compilers behave.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-04 18:04 -0700 |
| Message-ID | <ln4mi6w2ga.fsf@kst-u.example.com> |
| In reply to | #71861 |
supercat@casperkitty.com writes:
> On Sunday, October 4, 2015 at 4:07:14 PM UTC-5, Keith Thompson wrote:
>> I disagree. A compiler is free to define behavior that is not
>> defined by the standard. It's still strictly "undefined behavior",
>> which means only that the standard doesn't define the behavior,
>> but the implementation would still presumably be bound by its own
>> documentation. (The standard doesn't require implementations to
>> follow their own documentation; that's outside its scope.)
>
> If a behavior is categorized as Implementation-Defined, I would think that
> compliance with the Standard would mandate conformity with the documented
> behavior.
[snip]
Yes, I shouldhave mentioned that. The standard requires certain things
to be documented, and the standard implicitly requires such
documentation to be accurate.
> Otherwise, in the particular case I mentioned, it would certainly be possible
> for an implementation to expressly state that pointer accesses will process
> variables in the indicated fashion without regard for whether the program
> accesses them in the fashion required by the Standard (and such
> guarantees are not even terribly uncommon), in the absence of language which
> would expressly disclaim the requirement I think UB-ness would dominate; at
> least that's how some compilers behave.
The behavior of signed overflow is undefined. An implementation could
document that signed overflow always follows the common wraparound
semantics. If it behaved differently in some cases, that would be a bug
in the implementation, but not a violation of the standard.
Upthread you wrote that:
... modern philosophy seems to suggest that the fact that the
Standard regards something is undefined should negate even parts of
the compiler's own documentation which would otherwise describe the
behavior.
That's the part I was disagreeing with. The standard doesn't require
implementations to follow their own *additional* documentation, but it
doesn't override any such documentation.
--
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 | 2015-10-04 20:10 -0700 |
| Message-ID | <33e4862a-6fc4-4c99-9f8b-74cd388dfbef@googlegroups.com> |
| In reply to | #71911 |
On Sunday, October 4, 2015 at 8:04:27 PM UTC-5, Keith Thompson wrote:
> That's the part I was disagreeing with. The standard doesn't require
> implementations to follow their own *additional* documentation, but it
> doesn't override any such documentation.
If a compiler's documentation specifies that variables of type "uint32_t"
are stored as four bytes, little-endian, and variables of type "uint16_t"
are stored as two bytes, also little-endian, would that render the following
code defined?
uint8_t buff[4] = {0x78,0x56,0x34,0x12};
*((uint16_t*)buff) = 0x4321;
uint32_t l = (*(uint32_t*)x);
Implementations are required to document the storage formats for their
integer types, so if the fact that an implementation specifies how its types
are stored would render the prohibition against writing as one type and
reading another moot, then why include such a prohibition at all?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-04 22:15 -0700 |
| Message-ID | <lnmvvx6gmg.fsf@kst-u.example.com> |
| In reply to | #71924 |
supercat@casperkitty.com writes:
> On Sunday, October 4, 2015 at 8:04:27 PM UTC-5, Keith Thompson wrote:
>> That's the part I was disagreeing with. The standard doesn't require
>> implementations to follow their own *additional* documentation, but it
>> doesn't override any such documentation.
>
> If a compiler's documentation specifies that variables of type "uint32_t"
> are stored as four bytes, little-endian, and variables of type "uint16_t"
> are stored as two bytes, also little-endian, would that render the following
> code defined?
>
> uint8_t buff[4] = {0x78,0x56,0x34,0x12};
> *((uint16_t*)buff) = 0x4321;
> uint32_t l = (*(uint32_t*)x);
No, but that's not a case of the standard overriding the
implementation's documentation.
We know from the documentation that the types have a certain
representation, but that doesn't directly imply that reading an object
via a pointer to a different type will give meaningful results.
If the implementation's documentation defined the behavior of that code,
then that would make the code's behavior well defined for that
implementation.
Also, type-punning via a union would be well defined, since the standard
says that such an access reinterprets the object representation. (It
doesn't say so for pointer-based type-punning.)
> Implementations are required to document the storage formats for their
> integer types, so if the fact that an implementation specifies how its types
> are stored would render the prohibition against writing as one type and
> reading another moot, then why include such a prohibition at all?
There's no prohibition on such accesses, merely a statement that their
behavior is undefined.
--
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 | 2015-10-05 08:53 -0700 |
| Message-ID | <995425d1-0f9f-4086-b02c-9a48910336b4@googlegroups.com> |
| In reply to | #71937 |
On Monday, October 5, 2015 at 12:15:11 AM UTC-5, Keith Thompson wrote:
> We know from the documentation that the types have a certain
> representation, but that doesn't directly imply that reading an object
> via a pointer to a different type will give meaningful results.
I think the fundamental difficulty (which I'd like to discuss more on another
thread) is that from the moment the C89 Standard was published, there was a
major disconnect between the language documented in that Standard and the
language/dialects which were being used by microcomputer programmers. Almost
every C implementation used by microcomputer programmers through the 1980s
and 1990s could, and generally by default would, support type punning via
unions or pointers in ways which were entirely derived by the defined
representations and alignment requirements of their primitive types. The
C Standards have never recognized this, but I doubt that very many people
in the microcomputer scene perceived the omission as being relevant for
anyone writing programs that would never be expected to run on obscure
architectures.
If anyone had expected that microcomputer compilers might actually try to
prohibit writing memory using one pointer type and reading as another,
there would have been immediate demand for an efficient means by which code
could e.g. write a block of memory as a bunch of 32-bit values and then read
it back as twice that number of 16-bit values, and if such means were as
clean and efficient as simply writing using one type of pointer and reading
via another many coding standards would probably have required the use of
such means, and then it might after awhile be useful for let compilers make
optimizations on the assumption that it's not necessary to support type
punning except via the approved means.
As it was, however, no such means was ever defined because nobody saw any
problem with the status quo: microcomputer compilers simply support type
punning in the way they always have, and programmers write code that
uses the techniques that have always worked. All would be good were it
not for the fact that a new generation of compiler writers, that was not
around in the 1990s, has inferred, wrongly, from the lack of "official
blessing" for such behaviors, that they were never a legitimate programming
practice, and thus does not view new efforts to impose restrictions which
"officially" existed for decades but were never enforced as being a change
to the language.
On Monday, October 5, 2015 at 12:15:11 AM UTC-5, Keith Thompson wrote:
> supercat writes:
> > If a compiler's documentation specifies that variables of type "uint32_t"
> > are stored as four bytes, little-endian, and variables of type "uint16_t"
> > are stored as two bytes, also little-endian, would that render the following
> > code defined?
> >
> > uint8_t buff[4] = {0x78,0x56,0x34,0x12};
> > *((uint16_t*)buff) = 0x4321;
> > uint32_t l = (*(uint32_t*)x);
>
> No, but that's not a case of the standard overriding the
> implementation's documentation.
>
> We know from the documentation that the types have a certain
> representation, but that doesn't directly imply that reading an object
> via a pointer to a different type will give meaningful results.
[Assume I'd written the code in such a way as to guarantee that "buff" would
be word-aligned, which I now realize I failed to do in that particular
example]
In the absence of the prohibition against writing as one type and reading
as another, would there be any way in which, after the execution of the
second line, "buff" could contain anything other than {0x21,0x43,0x34,0x12},
given that the implementation specified that uint16_t is stored as two
bytes little-endian? In the absence of the prohibition, would there be
any way in which casting to uint32_t a pointer to a suitably-aligned
character buffer holding {0x21,0x43,0x34,0x12} and dereferencing it could
do anything other than yield 0x12344321, given that uint32_t is documented
as four bytes little-endian?
> If the implementation's documentation defined the behavior of that code,
> then that would make the code's behavior well defined for that
> implementation.
Some compiler writers take the viewpoint that even though the format of
primitive types is documented, there is no need to support writing as one
type and reading as another.
> There's no prohibition on such accesses, merely a statement that their
> behavior is undefined.
Some compiler writers take the viewpoint that compilers should assume that
programs will never receive input that would code to cause any action where
the Standard imposes no requirements, and use such inferences to eliminate
any code which would handle such inputs, even if the normal platform behavior
for the action where the Standard imposed no requirements would have been
benign or perhaps even helpful.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-06 08:45 -0700 |
| Message-ID | <lnk2r0knk8.fsf@kst-u.example.com> |
| In reply to | #71977 |
supercat@casperkitty.com writes:
> On Monday, October 5, 2015 at 12:15:11 AM UTC-5, Keith Thompson wrote:
[...]
>> If the implementation's documentation defined the behavior of that code,
>> then that would make the code's behavior well defined for that
>> implementation.
>
> Some compiler writers take the viewpoint that even though the format of
> primitive types is documented, there is no need to support writing as one
> type and reading as another.
Yes.
>> There's no prohibition on such accesses, merely a statement that their
>> behavior is undefined.
>
> Some compiler writers take the viewpoint that compilers should assume that
> programs will never receive input that would code to cause any action where
> the Standard imposes no requirements, and use such inferences to eliminate
> any code which would handle such inputs, even if the normal platform behavior
> for the action where the Standard imposed no requirements would have been
> benign or perhaps even helpful.
Yes. But that's still not a prohibition; the standard merely refrains
from defining the behavior. The way the standard phrases it is that "An
object shall have its stored value accessed only by an lvalue expression
that has one of the following types", followed by a list of types (N1570
6.5p7). The "shall" outside a constraint means that the behavior is
undefined -- i.e., the standard imposes no requirements.
You make some interesting points, but if your goal is to suggest changes
to the standard, I suggest using the standard's terminology as much as
possible.
--
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 | 2015-10-06 12:34 -0700 |
| Message-ID | <bda18c62-a1dc-4ace-8208-d966d3dd24ca@googlegroups.com> |
| In reply to | #72049 |
On Tuesday, October 6, 2015 at 10:46:15 AM UTC-5, Keith Thompson wrote: > Yes. But that's still not a prohibition; the standard merely refrains > from defining the behavior. The way the standard phrases it is that "An > object shall have its stored value accessed only by an lvalue expression > that has one of the following types", followed by a list of types (N1570 > 6.5p7). The "shall" outside a constraint means that the behavior is > undefined -- i.e., the standard imposes no requirements. The only way I can see by which the compilers' behavior would be justifiable would be if either it used sufficiently-hedged language wherever it describes the storage formats for objects, so as to expressly disclaim any equivalence between objects and their underlying char[] storage, or if any "shall" statement in the Standard is taken as a prohibition against doing anything to the contrary. In any case, I strongly suspect that the way compilers have started to interpret that part of the Standard is 100% contrary to the purpose for which it was written. There are two situations I can see where it might be useful: 1. If a hardware platform uses certain kinds of memory interfaces, writing something as e.g. a float and re-interpreting those bits an integer, may require an expensive intermediate step. Allowing things that may have been written as floats to be re-interpreted as integers would require that the compiler perform that expensive intermediate step any time it writes a float that might get re-interpreted as an integer, or any time it loads an integer that might have bee written as a float. Requiring the compiler to add the extra step in those cases would be much more expensive than requiring programmers to manually provide for it in cases where it was required. 2. In cases where a programmer would receive no benefit from type punning, it may be beneficial to have a compiler attempt to detect and trap accesses which would be prohibited under that rule. Prior to C99, I think all situations where a compiler could trap were labeled as Undefined Behavior; even in C99 the only exception I can think of is when performing narrowing signed integer conversions. BTW, I really dislike the use of "char" to get around those restrictions and think that should have been deprecated in favor of an explicit directive for the purpose [which could have been much more efficient] but I suspect that code which copied things as "char" existed before it was necessary to target a system where type punning would be problematic, and K & R didn't want to break such code. > You make some interesting points, but if your goal is to suggest changes > to the standard, I suggest using the standard's terminology as much as > possible. To what extent is "Thou shalt do X whenever one does Y" not a prohibition on doing Y without X?"? Such language grants compiler writers full freedom to interpret the statement as a prohibition, and unless a compiler writer specifically promises to uphold the rest of the Standard even when code violates that prohibition, there's no way programmers can know what guarantees a compiler would or would not make in such case. It would have IMHO been immensely more helpful if the Standard had regarded the availability of various access patterns as Implementation-Defined, but required that all implementations allow at least the listed forms. From a requirements standpoint, the only effect of that would have been to make some compiler writers add an extra couple lines to their documentation (which most did anyway), but such a statement would have avoided any ambiguity as to when such behavior is or is not defined on any particular platform.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-06 17:16 -0700 |
| Message-ID | <lnvbajjzwr.fsf@kst-u.example.com> |
| In reply to | #72081 |
supercat@casperkitty.com writes:
> On Tuesday, October 6, 2015 at 10:46:15 AM UTC-5, Keith Thompson wrote:
>> Yes. But that's still not a prohibition; the standard merely refrains
>> from defining the behavior. The way the standard phrases it is that "An
>> object shall have its stored value accessed only by an lvalue expression
>> that has one of the following types", followed by a list of types (N1570
>> 6.5p7). The "shall" outside a constraint means that the behavior is
>> undefined -- i.e., the standard imposes no requirements.
[...]
>> You make some interesting points, but if your goal is to suggest changes
>> to the standard, I suggest using the standard's terminology as much as
>> possible.
>
> To what extent is "Thou shalt do X whenever one does Y" not a prohibition
> on doing Y without X?"?
It would be really helpful if you'd refer to what the standard
actually says rather than paraphrasing it.
I just checked N1570, and you do have a point. Section 4 paragraph
1 says:
In this International Standard, "shall" is to be interpreted as
a requirement on an implementation or on a program; conversely,
"shall not" is to be interpreted as a prohibition.
And the "shall ... only" wording I quoted above is equivalent to
"shall not ... unless", so yes, the standard does refer to it as a
"prohibition".
On the other hand, paragraph 2 says:
If a "shall" or "shall not" requirement that appears outside of
a constraint or runtime-constraint is violated, the behavior is
undefined. Undefined behavior is otherwise indicated in this
International Standard by the words "undefined behavior" or by
the omission of any explicit definition of behavior. There is
no difference in emphasis among these three; they all describe
"behavior that is undefined".
And the definition of "undefined behavior" clearly says that no
particular action is required. It's an odd kind of "prohibition"
that isn't enforced.
Undefined behavior can also be an opportunity for language
extensions.
And as a practical matter, this program:
#include <stdio.h>
int main(void) {
float f = 1.0;
printf("0x%x\n", *(unsigned*)&f);
}
just printed 0x3f800000 on my system. (I get a warning about
strict-aliasing rules with the right compile-time options, but the
behavior is unchanged.)
> Such language grants compiler writers full freedom
> to interpret the statement as a prohibition, and unless a compiler writer
> specifically promises to uphold the rest of the Standard even when code
> violates that prohibition, there's no way programmers can know what
> guarantees a compiler would or would not make in such case.
Yes, the standard permits compilers to prohibit pointer-based
type-punning; a conforming compiler could refuse to translate my program
But in practice, the standard doesn't actually prohibit it itself (N1570
4p1 notwithstanding), and a conforming compiler could behave in exactly
the way you want it to.
[...]
--
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 | 2015-10-06 21:47 -0700 |
| Message-ID | <5861f87d-0660-44af-ba33-3b5f00a76508@googlegroups.com> |
| In reply to | #72103 |
On Tuesday, October 6, 2015 at 7:17:09 PM UTC-5, Keith Thompson wrote: > Yes, the standard permits compilers to prohibit pointer-based > type-punning; a conforming compiler could refuse to translate my program > But in practice, the standard doesn't actually prohibit it itself (N1570 > 4p1 notwithstanding), and a conforming compiler could behave in exactly > the way you want it to. The problem is that while the prohibition in the Standard doesn't prevent a compiler from generating code which behaves as the programmer intended, it makes it needlessly difficult to know from a compiler's documentation whether it will *always* yield such behavior. If a compiler would usually generate such code but may at arbitrary times do something totally different, the fact that it usually behaves as expected will be useless. Only behaviors that are predictable within known bounds are useful. Most compilers will behave as expected 99% of the time, but that will be of zero benefit if there's no way of predicting when they will do otherwise. I would posit that the benefit to the programmer of knowing that a piece of code will work 100% of the time instead of 99% is huge; the optimization benefit to the compiler of being able to throw the intended meaning of code out the window by eliminating a few code paths that would cause type-punning violations is, by comparison, minuscule.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-07 11:05 -0700 |
| Message-ID | <lnegh6k10i.fsf@kst-u.example.com> |
| In reply to | #72113 |
supercat@casperkitty.com writes:
> On Tuesday, October 6, 2015 at 7:17:09 PM UTC-5, Keith Thompson wrote:
>> Yes, the standard permits compilers to prohibit pointer-based
>> type-punning; a conforming compiler could refuse to translate my program
>> But in practice, the standard doesn't actually prohibit it itself (N1570
>> 4p1 notwithstanding), and a conforming compiler could behave in exactly
>> the way you want it to.
>
> The problem is that while the prohibition in the Standard doesn't prevent
> a compiler from generating code which behaves as the programmer intended,
> it makes it needlessly difficult to know from a compiler's documentation
> whether it will *always* yield such behavior. If a compiler would usually
> generate such code but may at arbitrary times do something totally
> different, the fact that it usually behaves as expected will be useless.
> Only behaviors that are predictable within known bounds are useful.
>
> Most compilers will behave as expected 99% of the time, but that will be
> of zero benefit if there's no way of predicting when they will do
> otherwise. I would posit that the benefit to the programmer of knowing
> that a piece of code will work 100% of the time instead of 99% is huge;
> the optimization benefit to the compiler of being able to throw the
> intended meaning of code out the window by eliminating a few code paths
> that would cause type-punning violations is, by comparison, minuscule.
But there's also a difference between knowing that something will work
99% of the time and knowing it will work 0% of the time, because the
compiler is required to reject it. The latter is a prohibition; the
former (again, in spite of the Standard's use of the word) is not.
The only point I'm making here is about your use of the word
"prohibition".
--
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 | 2015-10-07 11:47 -0700 |
| Message-ID | <81267d1a-e9c6-4831-87f2-f6cf5248a7c5@googlegroups.com> |
| In reply to | #72147 |
On Wednesday, October 7, 2015 at 1:05:34 PM UTC-5, Keith Thompson wrote:
> But there's also a difference between knowing that something will work
> 99% of the time and knowing it will work 0% of the time, because the
> compiler is required to reject it. The latter is a prohibition; the
> former (again, in spite of the Standard's use of the word) is not.
>
> The only point I'm making here is about your use of the word
> "prohibition".
If the Standard says code shall not do X, is there any verb you would
consider suitable for the sentence "The Standard ___s code from doing X"?
I would think "prohibit" would seem the most natural, but perhaps something
else would be better?
Also, in general the question of whether or not a particular C program is
conforming is dependent upon whether there is an implementation that will
process it as required. If a Standard-compliant C implementation defines
the behavior of writing some memory as long and reading it as short in a
fashion consistent with the intention of the following program, would
that make the program "conforming", or do implementations not have the
authority to override the rule which states that legitimate programs
shall not write a variable as one type and read as another
int main(void)
{
unsigned long foo = 0x00050005;
return *((unsigned short*)&foo);
}
Nothing prevents implementations from generating the same behavior as would
result from code which behaved as described in the implementation's
documentation, but if they don't have the authority to overrule the "shall
not" rule that would not make the program in question "conforming". On
the other hand, I think there's something strange with a definition of
conforming which would regard as non-conforming a source file whose meaning
would be well defined on a standard-conforming C implementation (on many
implementations, in fact), but could regard as a "conforming C program" a
text file containing a FORTRAN program whose first line was "C __X " [since
a C implementation may do anything it likes with any file containing an
identifier which starts with two underscores and has no standard-defined
meaning].
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-07 13:50 -0700 |
| Message-ID | <ln612ijtdz.fsf@kst-u.example.com> |
| In reply to | #72150 |
supercat@casperkitty.com writes:
> On Wednesday, October 7, 2015 at 1:05:34 PM UTC-5, Keith Thompson wrote:
>> But there's also a difference between knowing that something will work
>> 99% of the time and knowing it will work 0% of the time, because the
>> compiler is required to reject it. The latter is a prohibition; the
>> former (again, in spite of the Standard's use of the word) is not.
>>
>> The only point I'm making here is about your use of the word
>> "prohibition".
>
> If the Standard says code shall not do X, is there any verb you would
> consider suitable for the sentence "The Standard ___s code from doing X"?
> I would think "prohibit" would seem the most natural, but perhaps something
> else would be better?
If the Standard says code *shall* not do X, and the word "shall" is not
in a constraint, then (again, ignoring 4p1) it does not "prohibit" doing
X. That's because the Standard is using the word "shall" in a specific
technical sense that doesn't necessarily match common English usage.
Just by the ordinary English meaning of the verb "prohibit", telling you
that doing X has undefined consequences is not the same thing as
prohibiting X.
A compiler is prohibited from successfully translating a source file
containing a #error directive that survives preprocessing. If a program
prints the value of 2+2 and avoids any undefined or unspecified
behavior, the implementation is prohibited from generating code that
prints "5".
If your program does this:
int arr[10] = { 0 };
int *lastptr = arr + 10;
int last = *lastptr;
then its behavior is undefined. No diagnostic is required. Literally
all possible actions are permitted. I honestly don't understand why you
keep using the word "prohibition" to refer to that kind of thing.
If you want to argue that you're using the word "prohibition" in the
sense that the standard uses it in 4p1, then you have a point -- but I
don't *think* that's what you're doing (please correct me if I'm
mistaken on that point).
I suggest that "undefined behavior" is a better term. It's the one the
standard uses, it's accurate, and we all know what it means.
> Also, in general the question of whether or not a particular C program is
> conforming is dependent upon whether there is an implementation that will
> process it as required. If a Standard-compliant C implementation defines
> the behavior of writing some memory as long and reading it as short in a
> fashion consistent with the intention of the following program, would
> that make the program "conforming", or do implementations not have the
> authority to override the rule which states that legitimate programs
> shall not write a variable as one type and read as another
>
> int main(void)
> {
> unsigned long foo = 0x00050005;
> return *((unsigned short*)&foo);
> }
If you understand the way the standard uses the word "shall", you
should understand that an implementation is permitted to define
that behavior. N1570 4p6:
A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.
N1570 6.5p7 says:
An object shall have its stored value accessed only by an lvalue
expression that has one of the following types:
[...]
That is exactly equivalent to:
If an object has its stored value accessed by an lvalue expression
that does not have one of the following types:
[...]
then the behavior is undefined.
> Nothing prevents implementations from generating the same behavior as would
> result from code which behaved as described in the implementation's
> documentation, but if they don't have the authority to overrule the "shall
> not" rule that would not make the program in question "conforming".
There is nothing to "overrule". The behavior is undefined, which means
that the rule is infinitely permissive. In the presence of undefined
behavior (behavior that is not defined *by the Standard*), an
implementation is free to do anything it likes.
> On
> the other hand, I think there's something strange with a definition of
> conforming which would regard as non-conforming a source file whose meaning
> would be well defined on a standard-conforming C implementation (on many
> implementations, in fact), but could regard as a "conforming C program" a
> text file containing a FORTRAN program whose first line was "C __X " [since
> a C implementation may do anything it likes with any file containing an
> identifier which starts with two underscores and has no standard-defined
> meaning].
I agree that it's strange. I don't think that "conforming program" is a
particularly useful category. I think there was some politics behind
its inclusion in the standard.
--
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]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web