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 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-15 12:48 -0700 |
| Message-ID | <b5e302d6-b295-4039-a704-2892d39cab30@googlegroups.com> |
| In reply to | #72981 |
On Thursday, October 15, 2015 at 2:26:33 PM UTC-5, Tim Rentsch wrote:
> The comments from Keith Thompson said pretty much what I
> was going to say. The semantics of storing an int or
> float require storing all the bytes of the object in
> question, regardless of whether they are padding bits.
The semantics of storing an int or a float allow all bits to be written, and
require that all the bits of an object's representation be left in a state
which, if read, would report the proper state, but an implementation need
not write any bits which shouldn't be necessary to achieve that objective.
For example, on an 8086 compiler where "long long" values are held in four
machine words, the statement "longlongvar++" might be implemented as:
inc word [_longlongvar]
jnz done
inc word [_longlongvar+2]
jnz done
inc word [_longlongvar+4]
jnz done
inc word [_longlongvar+6]
done:
while code which used "adc" rather than branching could be more compact
and would be faster in the case where the bottom three words were 0xFFFF,
the above code would likely be much faster in the more common cases.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-17 08:21 -0700 |
| Message-ID | <kfnwpulh673.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #72985 |
supercat@casperkitty.com writes: > On Thursday, October 15, 2015 at 2:26:33 PM UTC-5, Tim Rentsch wrote: >> The comments from Keith Thompson said pretty much what I >> was going to say. The semantics of storing an int or >> float require storing all the bytes of the object in >> question, regardless of whether they are padding bits. > > The semantics of storing an int or a float allow all bits to be > written, and require that all the bits of an object's > representation be left in a state which, if read, would report > the proper state, but an implementation need not write any bits > which shouldn't be necessary to achieve that objective. For > example, on an 8086 compiler where "long long" values are held > in four machine words, the statement "longlongvar++" might be > implemented as: > > inc word [_longlongvar] > jnz done > inc word [_longlongvar+2] > jnz done > inc word [_longlongvar+4] > jnz done > inc word [_longlongvar+6] > done: > > while code which used "adc" rather than branching could be more > compact and would be faster in the case where the bottom three > words were 0xFFFF, the above code would likely be much faster > in the more common cases. The comments above are beside the point, because they are talking about what happens in the actual machine. In discussing semantics the question is what happens in the abstract machine. In the abstract machine all the bits must be stored.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-04 22:23 -0700 |
| Message-ID | <kfn37xp6g8d.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71714 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>
>> On Friday, October 2, 2015 at 3:32:49 PM UTC-4, Ben Bacarisse wrote:
>
> <snip>
>
>>> Undefined behaviour has a specific technical meaning in the C standard,
>>> and accessing a member from a union that is not the last one stored is
>>> *not* undefined behaviour. Lots of people seem to think that C has
>>> changed in this regard, but I don't think it has. It was never UB, and
>>> it still is not UB.
>>>
>>> After union { float f; uint32_t u; } u = { .f = 3.14 }; the expression
>>> u.u does not result in undefined behaviour. Because uint32_t has no
>>> padding bits (and thus no trap representations), u.u is guaranteed to be
>>> one of the 2^32 integer values a uint32_t can hold. Naturally, the C
>>> standard declines to say exactly what value it will be, but the
>>> behaviour is not undefined, merely unspecified.
>>
>> I'm curious what the difference is between unspecified and undefined
>> behavior in this context.
>
> The standard defines:
>
> 3.4.3
> 1 undefined behavior
> behavior, upon use of a nonportable or erroneous program construct
> or of erroneous data, for which this International Standard imposes
> no requirements
> 2 NOTE Possible undefined behavior ranges from ignoring the situation
> completely with unpredictable results, to behaving during
> translation or program execution in a documented manner
> characteristic of the environment (with or without the issuance of a
> diagnostic message), to terminating a translation or execution (with
> the issuance of a diagnostic message).
>
> and
>
> 3.4.4
> 1 unspecified behavior
> use of an unspecified value, or other behavior where this
> International Standard provides two or more possibilities and
> imposes no further requirements on which is chosen in any instance
>
> 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.
>
> 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.
The semantics of union member access is defined as a consequence
of (normative text that describes) union types and how lvalue
conversion works. The footnote is there only because that
consequence wasn't as apparent as people thought it should be.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-02 09:10 -0700 |
| Message-ID | <9e564d49-c531-420a-8d50-fe5fba789415@googlegroups.com> |
| In reply to | #71612 |
On Friday, October 2, 2015 at 10:07:16 AM UTC-5, Ben Bacarisse wrote:
> There's a misconception that keeps doing the rounds here which you are
> perpetuating. Using a union to reinterpret the bits of an object of one
> type as those of another is not off-standard or banned or not legal C or
> any of the other supposedly prohibited things it is sometimes said to
> be. For obvious reasons, the C standard doesn't say what the result
> will actually be in most cases, but it's no less legal or valid than
> writing CHAR_MAX + 1.
When, in C, did it first become possible to have two variables v1 and v2
of a union type U, such that given:
unsigned char x1[sizeof (U)], x2[sizeof (U)];
memcpy(x1, &v1, sizeof (U));
memcpy(x2, &v2, sizeof (U));
it would be possible for x1 and x2 to contain the same sequence of values
without v1 and v2 being equivalent? I recall that a major part of the C
philosophy was that the state of every object can be decomposed into a
sequence of "char" values. The Strict Aliasing Rule of C99 allows for
objects to have additional "hidden" state, but I don't think K&R C nor
C89 allowed that.
If "sizeof (float)" and "sizeof (long)" are both 4, what room would there
have been for a compiler given:
union { float f; long l; } u;
u.f = 1.0;
printf("%ld", u.l);
to do anything other than have "l" reinterpret the bits of 1.0 as a "long"?
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-10-02 11:58 -0500 |
| Message-ID | <mumd01$nbu$1@dont-email.me> |
| In reply to | #71618 |
On 10/2/2015 11:10 AM, supercat@casperkitty.com wrote:
> On Friday, October 2, 2015 at 10:07:16 AM UTC-5, Ben Bacarisse wrote:
>> There's a misconception that keeps doing the rounds here which you are
>> perpetuating. Using a union to reinterpret the bits of an object of one
>> type as those of another is not off-standard or banned or not legal C or
>> any of the other supposedly prohibited things it is sometimes said to
>> be. For obvious reasons, the C standard doesn't say what the result
>> will actually be in most cases, but it's no less legal or valid than
>> writing CHAR_MAX + 1.
>
> When, in C, did it first become possible to have two variables v1 and v2
> of a union type U, such that given:
>
> unsigned char x1[sizeof (U)], x2[sizeof (U)];
> memcpy(x1, &v1, sizeof (U));
> memcpy(x2, &v2, sizeof (U));
>
> it would be possible for x1 and x2 to contain the same sequence of values
> without v1 and v2 being equivalent?
What does this have to do with what Ben is talking about?
> I recall that a major part of the C
> philosophy was that the state of every object can be decomposed into a
> sequence of "char" values. The Strict Aliasing Rule of C99 allows for
> objects to have additional "hidden" state, but I don't think K&R C nor
> C89 allowed that.
Strict aliasing is about what the implementation can assume given the
types, not about state, hidden or otherwise.
> If "sizeof (float)" and "sizeof (long)" are both 4, what room would there
> have been for a compiler given:
>
> union { float f; long l; } u;
> u.f = 1.0;
> printf("%ld", u.l);
>
> to do anything other than have "l" reinterpret the bits of 1.0 as a "long"?
Nothing. However, it doesn't tell you what the effects of that
reinterpretation are, thus the behavior is unspecified.
Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-02 11:38 -0700 |
| Message-ID | <2afd05a8-ca24-40dd-af8d-583e576b4c4d@googlegroups.com> |
| In reply to | #71624 |
On Friday, October 2, 2015 at 11:58:47 AM UTC-5, Martin Shobe wrote:
> On 10/2/2015 11:10 AM, supercat wrote:
> > When, in C, did it first become possible to have two variables v1 and v2
> > of a union type U, such that given:
> >
> > unsigned char x1[sizeof (U)], x2[sizeof (U)];
> > memcpy(x1, &v1, sizeof (U));
> > memcpy(x2, &v2, sizeof (U));
> >
> > it would be possible for x1 and x2 to contain the same sequence of values
> > without v1 and v2 being equivalent?
>
> What does this have to do with what Ben is talking about?
If the state of a type is encapsulated entirely by the sequence of byte
values occupied by its storage, that would seem to imply that a union of
two types which occupy the same amount of storage with no padding bits
must allow for type punning.
> Strict aliasing is about what the implementation can assume given the
> types, not about state, hidden or otherwise.
Given:
// Assume sizeof(float)==sizeof(long)==4, and both 0.0f and 0L
// have the same bitwise representation
#include <stdio.h>
unsigned char global_buff[4];
void f1(int ch)
{
if (ch == '1')
*((float*)global_buff) = 0.0f;
else
*((long*)global_buff) = 0;
}
void f2(int ch)
{
if (ch == '1')
printf("%f",*((float*)global_buff));
else
printf("%ld",*((long*)global_buff));
}
int main(void)
{
f1(getchar());
f2(getchar());
return 0;
}
Between the call to "f1()" and "f2()" the program may be in either of two
states--one which will only have defined behavior of the next call to
'getchar' returns 1, and one which will only have defined behavior if the
next call to 'getchar' returns something else. In one of the states,
global_buff has 0.0f stored in it and in the other it has 0L stored in it.
The Strict Aliasing Rule would allow the compiler to distinguish between
those two states if it so chose, but there is no mechanism via which code
added between the calls to "f1()" and "f2()" [not counting cheats like
examining I/O buffers] could determine what character must be typed in
order to avoid Undefined Behavior.
> Nothing. However, it doesn't tell you what the effects of that
> reinterpretation are, thus the behavior is unspecified.
If both types are the same size, and neither has padding, what freedom would
a C compiler have to do anything other than take the sequence of bytes that
represent the first value (*which a compiler is required to document*), and
convert that sequence of bytes to a value of the second type (*which a
compiler is also required to document*)? If either type has padding, the
treatment of such padding need not be specified, but I don't think C89 gave
any wiggle room with regard to the behavior of unions where both types'
representations were fully specified.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-10-05 09:36 -0500 |
| Message-ID | <muu1qe$iko$1@dont-email.me> |
| In reply to | #71632 |
On 10/2/2015 1:38 PM, supercat@casperkitty.com wrote:
> On Friday, October 2, 2015 at 11:58:47 AM UTC-5, Martin Shobe wrote:
>> On 10/2/2015 11:10 AM, supercat wrote:
>>> When, in C, did it first become possible to have two variables v1 and v2
>>> of a union type U, such that given:
>>>
>>> unsigned char x1[sizeof (U)], x2[sizeof (U)];
>>> memcpy(x1, &v1, sizeof (U));
>>> memcpy(x2, &v2, sizeof (U));
>>>
>>> it would be possible for x1 and x2 to contain the same sequence of values
>>> without v1 and v2 being equivalent?
>>
>> What does this have to do with what Ben is talking about?
>
> If the state of a type is encapsulated entirely by the sequence of byte
> values occupied by its storage, that would seem to imply that a union of
> two types which occupy the same amount of storage with no padding bits
> must allow for type punning.'
Unions already allow for type punning, even when there are padding bits.
That doesn't answer my question.
>> Strict aliasing is about what the implementation can assume given the
>> types, not about state, hidden or otherwise.
> Given:
>
> // Assume sizeof(float)==sizeof(long)==4, and both 0.0f and 0L
> // have the same bitwise representation
>
> #include <stdio.h>
>
> unsigned char global_buff[4];
>
> void f1(int ch)
> {
> if (ch == '1')
> *((float*)global_buff) = 0.0f;
> else
> *((long*)global_buff) = 0;
> }
> void f2(int ch)
> {
> if (ch == '1')
> printf("%f",*((float*)global_buff));
> else
> printf("%ld",*((long*)global_buff));
> }
> int main(void)
> {
> f1(getchar());
> f2(getchar());
> return 0;
> }
>
> Between the call to "f1()" and "f2()" the program may be in either of two
> states--one which will only have defined behavior of the next call to
> 'getchar' returns 1, and one which will only have defined behavior if the
> next call to 'getchar' returns something else. In one of the states,
> global_buff has 0.0f stored in it and in the other it has 0L stored in it.
> The Strict Aliasing Rule would allow the compiler to distinguish between
> those two states if it so chose, but there is no mechanism via which code
> added between the calls to "f1()" and "f2()" [not counting cheats like
> examining I/O buffers] could determine what character must be typed in
> order to avoid Undefined Behavior.
I see how one might consider that a hidden state.
>> Nothing. However, it doesn't tell you what the effects of that
>> reinterpretation are, thus the behavior is unspecified.
> If both types are the same size, and neither has padding, what freedom would
> a C compiler have to do anything other than take the sequence of bytes that
> represent the first value (*which a compiler is required to document*), and
> convert that sequence of bytes to a value of the second type (*which a
> compiler is also required to document*)? If either type has padding, the
> treatment of such padding need not be specified, but I don't think C89 gave
> any wiggle room with regard to the behavior of unions where both types'
> representations were fully specified.
You've added extra conditions. Neither float nor long meet those
requirements you just added. (They might, but they also might not.)
However, even if you do meet those conditions, the C standard does not
tell you what the mapping is. (And where is the requirement that the
object representations of a float be documented?)
Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-12 09:47 -0700 |
| Message-ID | <kfnwpuskp9q.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71969 |
Martin Shobe <martin.shobe@yahoo.com> writes:
> [..discussing "type punning" union access..]
>
> However, even if you do meet those conditions, the C standard does not
> tell you what the mapping is. (And where is the requirement that the
> object representations of a float be documented?)
6.2.6.1 p2 says:
Except for bit-fields, objects are composed of contiguous
sequences of one or more bytes, the number, order, and
encoding of which are either explicitly specified or
implementation-defined.
To me this implies that enough documentation must be provided so
that the object representation of float can be deduced, if it
isn't described directly. Is there any other way to interpret
this paragraph so that does not hold?
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-13 02:51 +0000 |
| Message-ID | <mvhrim$48o$1@speranza.aioe.org> |
| In reply to | #72640 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > Martin Shobe <martin.shobe@yahoo.com> writes: >> [..discussing "type punning" union access..] >> However, even if you do meet those conditions, the C standard does not >> tell you what the mapping is. (And where is the requirement that the >> object representations of a float be documented?) > 6.2.6.1 p2 says: > Except for bit-fields, objects are composed of contiguous > sequences of one or more bytes, the number, order, and > encoding of which are either explicitly specified or > implementation-defined. > To me this implies that enough documentation must be provided so > that the object representation of float can be deduced, if it > isn't described directly. Is there any other way to interpret > this paragraph so that does not hold? Hmmm, I wouldn't have read it that way. You can have padding bits, and as far as I know, they can be between the sign and value bits. For hardware with floating point, it is usually defined along with the hardware. For software floating point, it might not be. As a quality of implementation issue, it seems to me that the formats should be defined, but I didn't know that C required it. In the case of floating point, you have sign, exponent, and significand. As well as I know it, C doesn't have a requirement on the order of the three, or even the bit order within them. (Maybe little-endian significand and big endian exponent.) Or even VAX ordered bits for floating point. -- glen
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-12 23:45 -0700 |
| Message-ID | <523fcf0d-3627-41a6-8d6a-3488d3f3f840@googlegroups.com> |
| In reply to | #72673 |
On Monday, October 12, 2015 at 9:51:13 PM UTC-5, glen herrmannsfeldt wrote:
> In the case of floating point, you have sign, exponent, and
> significand. As well as I know it, C doesn't have a requirement
> on the order of the three, or even the bit order within them.
> (Maybe little-endian significand and big endian exponent.)
Even for integer types, I don't think there's anything in the C Standard
which would say anything about bit ordering. From what I can tell, nothing
would forbid a compiler where both "int" and "long" were 32 bits no padding,
where the effect of:
union { uint32_t v1; unsigned int v2; unsigned long v3; } triple32;
triple32.v1 = 0x12345678;
printf("%lX %X %lX", (long)v1, v2, v3);
would be to print out "12345678 87654321 13572468" [the fact that all three
types are 32 bits without padding does not imply that the same bits cannot
be arbitrarily permuted among them].
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-15 13:54 -0700 |
| Message-ID | <kfnr3kvj1jf.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #72673 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: >> Martin Shobe <martin.shobe@yahoo.com> writes: >> >>> [..discussing "type punning" union access..] >>> >>> However, even if you do meet those conditions, the C standard does not >>> tell you what the mapping is. (And where is the requirement that the >>> object representations of a float be documented?) >> >> 6.2.6.1 p2 says: >> >> Except for bit-fields, objects are composed of contiguous >> sequences of one or more bytes, the number, order, and >> encoding of which are either explicitly specified or >> implementation-defined. >> >> To me this implies that enough documentation must be provided so >> that the object representation of float can be deduced, if it >> isn't described directly. Is there any other way to interpret >> this paragraph so that does not hold? > > Hmmm, I wouldn't have read it that way. You can have padding > bits, and as far as I know, they can be between the sign and > value bits. [snip elaboration] Even if float or some other type has extraneous bits (the term 'padding bits' being limited to integer types), these bits are part of the object representation of the type, which is what is being talked about above. Even if they aren't part of the type's /value/, they are part of the encoding of its object bytes, and so must be implementation-defined if not explicitly specified. That is true even if there is no semantics associated with difference choices of zeroes/ones for the extraneous bits, in that the encoding specification needs to say "unused bit" or at least words to that effect. Obviously if the extraneous bits have any associated semantics (eg, some sort of value checksum), how different values of those bits encode their respective semantics is also reflected in the encoding of the bytes of such objects (and hence must be implementation-defined if not defined in the Standard). If we know the encoding of all the bits that make up the bytes that constitute the object representation of a type, that pretty much completely constrains the type's representation. Do you agree with all that? If not what part do you not agree with?
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-16 01:07 +0000 |
| Message-ID | <mvpila$5kg$1@speranza.aioe.org> |
| In reply to | #72991 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: >> Tim Rentsch <txr@alumni.caltech.edu> wrote: (snip) >>> To me this implies that enough documentation must be provided so >>> that the object representation of float can be deduced, if it >>> isn't described directly. Is there any other way to interpret >>> this paragraph so that does not hold? >> Hmmm, I wouldn't have read it that way. You can have padding >> bits, and as far as I know, they can be between the sign and >> value bits. [snip elaboration] > Even if float or some other type has extraneous bits (the term > 'padding bits' being limited to integer types), these bits are > part of the object representation of the type, which is what is > being talked about above. Even if they aren't part of the type's > /value/, they are part of the encoding of its object bytes, and > so must be implementation-defined if not explicitly specified. OK, for some actual cases. Some systems store the intel temporary real (80 bit) floating point format in 16 bytes. What do you call the extra bits? The IBM 7090 and related systems store 16 bit sign magnitude integers in 36 bit words. I believe that there are bits between the sign and the value bits. There are systems where there is no difference between floating point and integers. The floating point system normalizes such that integer values have the appropriate integer format, with zero exponent field. > That is true even if there is no semantics associated with > difference choices of zeroes/ones for the extraneous bits, in > that the encoding specification needs to say "unused bit" or > at least words to that effect. Obviously if the extraneous > bits have any associated semantics (eg, some sort of value > checksum), how different values of those bits encode their > respective semantics is also reflected in the encoding of the > bytes of such objects (and hence must be implementation-defined > if not defined in the Standard). If we know the encoding of > all the bits that make up the bytes that constitute the > object representation of a type, that pretty much completely > constrains the type's representation. Do you agree with all > that? If not what part do you not agree with? -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-19 15:33 -0700 |
| Message-ID | <kfnfv16fpyk.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #73003 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: >> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: >>> Tim Rentsch <txr@alumni.caltech.edu> wrote: > > (snip) > >>>> To me this implies that enough documentation must be provided so >>>> that the object representation of float can be deduced, if it >>>> isn't described directly. Is there any other way to interpret >>>> this paragraph so that does not hold? >>> >>> Hmmm, I wouldn't have read it that way. You can have padding >>> bits, and as far as I know, they can be between the sign and >>> value bits. [snip elaboration] >> >> Even if float or some other type has extraneous bits (the term >> 'padding bits' being limited to integer types), these bits are >> part of the object representation of the type, which is what is >> being talked about above. Even if they aren't part of the type's >> /value/, they are part of the encoding of its object bytes, and >> so must be implementation-defined if not explicitly specified. > > OK, for some actual cases. > > Some systems store the intel temporary real (80 bit) floating > point format in 16 bytes. What do you call the extra bits? > > The IBM 7090 and related systems store 16 bit sign > magnitude integers in 36 bit words. I believe that there > are bits between the sign and the value bits. > > There are systems where there is no difference between > floating point and integers. The floating point system > normalizes such that integer values have the appropriate > integer format, with zero exponent field. I don't really understand what question you're trying to ask. The C standard uses certain terms only the in the context of a C abstract machine, not physical hardware. In a C abstract machine, bits in the object representation of an integer type that do not participate in determining the integer's value are called 'padding bits' by the Standard. There is no corresponding term for floating point types. In either case, which bits participate in determining the value of an object, and which bits do not participate in that determination, depends on what type the object is interpreted as. Both kinds of bits (ie, of the type in question) are still part of the object representation.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-02 19:21 +0100 |
| Message-ID | <87mvw1qggo.fsf@bsb.me.uk> |
| In reply to | #71618 |
supercat@casperkitty.com writes:
> On Friday, October 2, 2015 at 10:07:16 AM UTC-5, Ben Bacarisse wrote:
>> There's a misconception that keeps doing the rounds here which you are
>> perpetuating. Using a union to reinterpret the bits of an object of one
>> type as those of another is not off-standard or banned or not legal C or
>> any of the other supposedly prohibited things it is sometimes said to
>> be. For obvious reasons, the C standard doesn't say what the result
>> will actually be in most cases, but it's no less legal or valid than
>> writing CHAR_MAX + 1.
>
> When, in C, did it first become possible to have two variables v1 and v2
> of a union type U, such that given:
>
> unsigned char x1[sizeof (U)], x2[sizeof (U)];
> memcpy(x1, &v1, sizeof (U));
> memcpy(x2, &v2, sizeof (U));
>
> it would be possible for x1 and x2 to contain the same sequence of values
> without v1 and v2 being equivalent?
I don't understand the question, mainly because I don't know what you
means by equivalent here. Maybe if you gave a full example of what you
think is wrong or has changed about C, it would be clear to me.
> I recall that a major part of the C
> philosophy was that the state of every object can be decomposed into a
> sequence of "char" values. The Strict Aliasing Rule of C99 allows for
> objects to have additional "hidden" state, but I don't think K&R C nor
> C89 allowed that.
Again, I'm not sure what this hidden state is. Do you mean the
effective type of the object? If so, what point are you making in
regard to unions?
> If "sizeof (float)" and "sizeof (long)" are both 4, what room would there
> have been for a compiler given:
>
> union { float f; long l; } u;
> u.f = 1.0;
> printf("%ld", u.l);
>
> to do anything other than have "l" reinterpret the bits of 1.0 as a
> "long"?
And now it is the hypothetical that is confusing me. I don't think
there has ever been any permission for the above code to anything but
reinterpret the bits of u.f and a long. Do you think I've been saying
otherwise? Do you think there is or once was such permission?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-02 12:10 -0700 |
| Message-ID | <376c05c3-ee5a-4cc9-b910-6a9d753aa4f1@googlegroups.com> |
| In reply to | #71631 |
On Friday, October 2, 2015 at 1:21:44 PM UTC-5, Ben Bacarisse wrote:
> supercat writes:
> > On Friday, October 2, 2015 at 10:07:16 AM UTC-5, Ben Bacarisse wrote:
> >> For obvious reasons, the C standard doesn't say what the result
> >> will actually be in most cases, but it's no less legal or valid than
> >> writing CHAR_MAX + 1.
> >
> > When, in C, did it first become possible...
> I don't understand the question, mainly because I don't know what you
> means by equivalent here. Maybe if you gave a full example of what you
> think is wrong or has changed about C, it would be clear to me.
I suppose one possible point of confusion is what is meant by "most cases".
Many compilers document the way in which they store various types precisely
even in cases where the Standard does not require it. I would suggest that
if an implementation documents precisely how two types are stored, there
isn't any wiggle room for what a C89 compiler will do if one type is stored
to the union and the other is read out. Most code which would use unions
for type punning is targeted toward such implementations, so in at least
some sense the behavior was defined in "most cases".
> > I recall that a major part of the C
> > philosophy was that the state of every object can be decomposed into a
> > sequence of "char" values. The Strict Aliasing Rule of C99 allows for
> > objects to have additional "hidden" state, but I don't think K&R C nor
> > C89 allowed that.
>
> Again, I'm not sure what this hidden state is. Do you mean the
> effective type of the object? If so, what point are you making in
> regard to unions?
In cases where two types' representations are completely documented, if
storing some value of one type in a union would result in a program
executing with completely defined behavior, and storing a value of some
other type which is documented as having the same bit-level representation
would invoke Undefined Behavior, that would imply that a compiler is allowed
to keep track of what type was stored in the union even though there is
no defined mechanism by which that could happen.
> > If "sizeof (float)" and "sizeof (long)" are both 4, what room would there
> > have been for a compiler given:
> >
> > union { float f; long l; } u;
> > u.f = 1.0;
> > printf("%ld", u.l);
> >
> > to do anything other than have "l" reinterpret the bits of 1.0 as a
> > "long"?
>
> And now it is the hypothetical that is confusing me. I don't think
> there has ever been any permission for the above code to anything but
> reinterpret the bits of u.f and a long. Do you think I've been saying
> otherwise? Do you think there is or once was such permission?
Some people seem to think that such permission exists, and that behavior is
only defined in cases where values are read and written as the same type.
Prior to C99 I don't think anyone perceived there as being any wiggle room,
and I don't know that any compilers behaved as though there were; in C++,
type punning in the general case (where one or both types may have virtual
members) invokes Undefined Behavior, and I don't think the Standard has
done anything to clarify that in cases where two types have documented
representations, implementations are required to behave in terms of those
representations, and type punning may only trigger Undefined Behavior in
cases where the bytes interpreted as an rvalue of some type could hold a
trap representation for that type.
As it is, there's still a lot of murkiness about things like:
union U { float f; long l; } u;
u.l = 1234;
scanf("%f", &u.f);
printf("%08lX", u.l);
The intention of scanf is that it should store some value into u.f, but
scanf doesn't store to a (union U*) but instead to a "float*", so it's
not clear whether a compiler would be required to store 1234 into the
memory associated with "u" before the scanf and read it back afterward.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-02 21:24 +0100 |
| Message-ID | <877fn5qas8.fsf@bsb.me.uk> |
| In reply to | #71633 |
supercat@casperkitty.com writes:
> On Friday, October 2, 2015 at 1:21:44 PM UTC-5, Ben Bacarisse wrote:
>> supercat writes:
>> > On Friday, October 2, 2015 at 10:07:16 AM UTC-5, Ben Bacarisse wrote:
>> >> For obvious reasons, the C standard doesn't say what the result
>> >> will actually be in most cases, but it's no less legal or valid than
>> >> writing CHAR_MAX + 1.
>> >
>> > When, in C, did it first become possible...
>
>> I don't understand the question, mainly because I don't know what you
>> means by equivalent here. Maybe if you gave a full example of what you
>> think is wrong or has changed about C, it would be clear to me.
>
> I suppose one possible point of confusion is what is meant by "most cases".
> Many compilers document the way in which they store various types precisely
> even in cases where the Standard does not require it. I would suggest that
> if an implementation documents precisely how two types are stored, there
> isn't any wiggle room for what a C89 compiler will do if one type is stored
> to the union and the other is read out. Most code which would use unions
> for type punning is targeted toward such implementations, so in at least
> some sense the behavior was defined in "most cases".
>
>> > I recall that a major part of the C
>> > philosophy was that the state of every object can be decomposed into a
>> > sequence of "char" values. The Strict Aliasing Rule of C99 allows for
>> > objects to have additional "hidden" state, but I don't think K&R C nor
>> > C89 allowed that.
>>
>> Again, I'm not sure what this hidden state is. Do you mean the
>> effective type of the object? If so, what point are you making in
>> regard to unions?
>
> In cases where two types' representations are completely documented, if
> storing some value of one type in a union would result in a program
> executing with completely defined behavior, and storing a value of some
> other type which is documented as having the same bit-level representation
> would invoke Undefined Behavior, that would imply that a compiler is allowed
> to keep track of what type was stored in the union even though there is
> no defined mechanism by which that could happen.
>
>> > If "sizeof (float)" and "sizeof (long)" are both 4, what room would there
>> > have been for a compiler given:
>> >
>> > union { float f; long l; } u;
>> > u.f = 1.0;
>> > printf("%ld", u.l);
>> >
>> > to do anything other than have "l" reinterpret the bits of 1.0 as a
>> > "long"?
>>
>> And now it is the hypothetical that is confusing me. I don't think
>> there has ever been any permission for the above code to anything but
>> reinterpret the bits of u.f and a long. Do you think I've been saying
>> otherwise? Do you think there is or once was such permission?
>
> Some people seem to think that such permission exists, and that behavior is
> only defined in cases where values are read and written as the same
> type.
Saying that something is not undefined behaviour does not mean that it
is defined!
I see zero wriggle room for anyone to say the access of u.l above is
undefined behaviour (though if anyone does, please say chip in say why).
But that does not mean that u.l is defined, or well-defined or
fully-defined or any other similar natural language term. The result
depends on all sorts of things and the standard does not ask for all
these things to be documented, which is why it is unspecified behaviour
rather than implementation-defined behaviour.
I know that unspecified behaviour can include cases that are truly
undefined. For example if long has padding bits and trap
representations the result of evaluating u.l may be undefined behaviour,
but that is not due to the union access.
> Prior to C99 I don't think anyone perceived there as being any wiggle room,
> and I don't know that any compilers behaved as though there were; in C++,
> type punning in the general case (where one or both types may have virtual
> members) invokes Undefined Behavior, and I don't think the Standard has
> done anything to clarify that in cases where two types have documented
> representations, implementations are required to behave in terms of those
> representations, and type punning may only trigger Undefined Behavior in
> cases where the bytes interpreted as an rvalue of some type could hold a
> trap representation for that type.
Sorry, I can't see where you stop talking about C++ there so I don't know
how to comment.
> As it is, there's still a lot of murkiness about things like:
>
> union U { float f; long l; } u;
> u.l = 1234;
> scanf("%f", &u.f);
> printf("%08lX", u.l);
>
> The intention of scanf is that it should store some value into u.f, but
> scanf doesn't store to a (union U*) but instead to a "float*", so it's
> not clear whether a compiler would be required to store 1234 into the
> memory associated with "u" before the scanf and read it back
> afterward.
This code contravenes a "shall" in the standard by not passing an
unsigned long as printf's second argument but I don't suppose that is
the murkiness you are referring to.
I don't see what you are worried about. Setting *&u.f via scanf is
fine. Reading u.l is also fine, but the result is unspecified and it
could be catastrophic if long has trap representations. I don't see why
you think 1234 needs to be read back (thought it might be, of course).
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-02 14:32 -0700 |
| Message-ID | <9b5075ac-ac18-44d4-888b-89e8f022aa27@googlegroups.com> |
| In reply to | #71640 |
On Friday, October 2, 2015 at 3:24:19 PM UTC-5, Ben Bacarisse wrote:
> supercat writes:
> > As it is, there's still a lot of murkiness...
> This code contravenes a "shall" in the standard by not passing an
> unsigned long as printf's second argument but I don't suppose that is
> the murkiness you are referring to.
That was simply a slight goof on my part.
> I don't see what you are worried about. Setting *&u.f via scanf is
> fine. Reading u.l is also fine, but the result is unspecified and it
> could be catastrophic if long has trap representations. I don't see why
> you think 1234 needs to be read back (thought it might be, of course).
If the code were changed to:
union U { float f; unsigned long l; };
void evil(union U *up, float *fp, unsigned long *lp, int mode)
{
if (mode & 1) *lp = 0x12345678;
if (mode & 2) *fp = 12.34;
if (mode & 16) up->l = 0xAABBCCDD;
if (mode & 4) printf("%08lX ", &lp);
if (mode & 8) printf("%f ", &fp);
}
int main(int argc)
{
union U u;
u.l = 0xABCD1234;
evil(&u, &(u.f), &(u.l), argc);
printf("u.l=%08lX\n", u.l);
return 0;
}
a compiler would, because of the Strict Aliasing Rule be under no obligation
to notice that the write to *fp might affect the value of *lp when argc==15.
Indeed, because of the Strict Aliasing Rule, a compiler could do anything it
likes with the above code in that case (writing a memory location with one
pointer type and reading with another is UB in the general case, and none of
the exceptions are applicable to the above code). What's less clear is what
behaviors would be permissible by the Standard for other values of argc.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-02 23:43 +0100 |
| Message-ID | <87vbaoq4bo.fsf@bsb.me.uk> |
| In reply to | #71644 |
supercat@casperkitty.com writes:
> On Friday, October 2, 2015 at 3:24:19 PM UTC-5, Ben Bacarisse wrote:
>> supercat writes:
>> > As it is, there's still a lot of murkiness...
<snip>
>> I don't see what you are worried about. Setting *&u.f via scanf is
>> fine. Reading u.l is also fine, but the result is unspecified and it
>> could be catastrophic if long has trap representations. I don't see why
>> you think 1234 needs to be read back (thought it might be, of course).
>
> If the code were changed to:
Ah. Another example. OK, but it does not shed any light on what
murkiness you saw in your last example. I'd like to clear that up first
(since it seemed to confirm a common misconception) but if you can't say
more about what was murky about it then let's leave it. Do you at least
agree that accessing a union member other than the one last stored is
unspecified behaviour rather than undefined behaviour per se?
> union U { float f; unsigned long l; };
>
> void evil(union U *up, float *fp, unsigned long *lp, int mode)
> {
> if (mode & 1) *lp = 0x12345678;
> if (mode & 2) *fp = 12.34;
> if (mode & 16) up->l = 0xAABBCCDD;
> if (mode & 4) printf("%08lX ", &lp);
> if (mode & 8) printf("%f ", &fp);
> }
>
> int main(int argc)
> {
> union U u;
> u.l = 0xABCD1234;
> evil(&u, &(u.f), &(u.l), argc);
> printf("u.l=%08lX\n", u.l);
> return 0;
> }
>
> a compiler would, because of the Strict Aliasing Rule be under no obligation
> to notice that the write to *fp might affect the value of *lp when
> argc==15.
Why the capital letters in "Strict Aliasing Rule"? It makes it sound
like there is a well-known thing with that agreed name.
Anyway, this example is about aliasing and C's effective type rules.
Does that mean you think your previous example broke C's effective type
rules?
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-02 16:49 -0700 |
| Message-ID | <9a154551-4b77-44d1-9c39-1951be7e3d22@googlegroups.com> |
| In reply to | #71647 |
On Friday, October 2, 2015 at 5:43:49 PM UTC-5, Ben Bacarisse wrote: > Ah. Another example. OK, but it does not shed any light on what > murkiness you saw in your last example. I'd like to clear that up first > (since it seemed to confirm a common misconception) but if you can't say > more about what was murky about it then let's leave it. Do you at least > agree that accessing a union member other than the one last stored is > unspecified behaviour rather than undefined behaviour per se? What I have maintained is all along is that when all access are made using lvalues that are *directly accessed* as part of the union type, the C Standard does not say anything about the behavior *beyond* what implementations document about the representations of the data types involve, but does require that behavior be consistent with the documented representations. What was murky in the original example is whether a write to a float* by scanf is required to be recognized as aliasing the float stored within the union and, in turn, aliasing the other parts of that same union. If a write directly to "u.f" is required to be recognized as aliasing "u.l" but it's less clear whether taking the address of "u.f" would compel a compiler to recognize a write to that pointer as a write to "u" or any of its members. > Why the capital letters in "Strict Aliasing Rule"? It makes it sound > like there is a well-known thing with that agreed name. C99 added a new rule which is commonly referred to using the phrase "strict aliasing rule". Although the phrase is often written in lowercase, I would suggest that because it is used to refer to a specific rule added in C99 it is proper to regard the phrase as a proper noun when used to refer to that new rule in particular, as opposed to any strict rule having to do with aliasing.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-03 02:01 +0100 |
| Message-ID | <87k2r4pxxz.fsf@bsb.me.uk> |
| In reply to | #71651 |
supercat@casperkitty.com writes:
> On Friday, October 2, 2015 at 5:43:49 PM UTC-5, Ben Bacarisse wrote:
>> Ah. Another example. OK, but it does not shed any light on what
>> murkiness you saw in your last example. I'd like to clear that up first
>> (since it seemed to confirm a common misconception) but if you can't say
>> more about what was murky about it then let's leave it. Do you at least
>> agree that accessing a union member other than the one last stored is
>> unspecified behaviour rather than undefined behaviour per se?
>
> What I have maintained is all along is that when all access are made
> using lvalues that are *directly accessed* as part of the union type,
> the C Standard does not say anything about the behavior *beyond* what
> implementations document about the representations of the data types
> involve, but does require that behavior be consistent with the documented
> representations.
>
> What was murky in the original example is whether a write to a float* by
> scanf is required to be recognized as aliasing the float stored within
> the union and, in turn, aliasing the other parts of that same union. If
> a write directly to "u.f" is required to be recognized as aliasing "u.l"
> but it's less clear whether taking the address of "u.f" would compel a
> compiler to recognize a write to that pointer as a write to "u" or any
> of its members.
Ah right. I find that much clearer, thank you. Here's the code again
(with the printf format tweaked):
| union U { float f; long l; } u;
| u.l = 1234;
| scanf("%f", &u.f);
| printf("%ld", u.l);
We both seem to agree that the following version is fine:
u.f = 1.234f;
printf("%ld", u.l);
and that you will get some peculiar integer value derived from the
representation of 1.234f. What about this:
*&u.f = 1.234f;
printf("%ld", u.l);
and, finally, this:
void set(float *fp) { *fp = 1.234f; }
...
set(&u.f);
printf("%ld", u.l);
? Do any of these have the murkiness you see with the scanf one, and if
so, where does the trouble lie? Specifically, how does it relate to C's
effective type rules? I find the rules rather odd[1], but they don't
explicitly distinguish between any of these cases as far as I can see.
[1] There's a defect report that captures what bothers me about them,
but it seems not to have been given a number much less decided:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1409.htm
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 8 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