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 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-04 06:23 -0700 |
| Message-ID | <2715106c-5fe6-44be-a32f-dec76b362fe1@googlegroups.com> |
| In reply to | #71798 |
On Sunday, October 4, 2015 at 8:35:58 AM UTC-4, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > > 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." > > What an odd reading of that paragraph. How's it odd? "C90 did not explicitly require [the result of reading one member] ... to have anything to do with [a previous write to another member]..." To me it's completely straight-forward that's what he's saying. > Anyway, C90 does not permit > non-overlapping union members. Pointers to all union members must > compare equal (when suitably converted). As it should be. > >> > 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... > > That's going to cause some problems in a group like this. I would urge > you to use another English phrase. I don't place much emphasis on the C Standard phrases because most people who come here (myself included) aren't experts in the C Standard, and have no desire to become experts. What they desire to know is how things work in normal English words, and not C Standard words. I think it should be such that in comp.lang.c when you use some phrase that has a particular meaning in the C Standard it should be put in quotes, or brackets, or something to identify that it's a particular phrase that's not in line with the standard English language meaning. > Even so your remark makes no sense. The result is "not fully defined in > the English sense" is all cases. There is nothing about your incorrect > interpretation of Keith's remark that specifically makes it so. Hmm... Re-read how I read Keith's post above, and I think you'll find it does make sense, because I read it to mean that a union containing these length items: 1: [x] 4: [xxxx] 8: [xxxxxxxx] That to read the 1 item it would not have to have any read-back from a prior write to the 4 or 8 item. As such, it would have to be separate and distinct, in its own memory space, otherwise it would read-back a value from the prior write. That was my understanding of his paragraph, and upon reflection I think that's a proper read from that paragraph because I didn't also know the constraint you mentioned afterward, that the void* of all members must evaluate to the same value. > In you > sense of the word, C90 makes the type of access being discussed "not > fully defined" regardless of whether the members overlap or not. It's still confusing to me. Something that's not fully defined is scarcely different than being undefined in practical use because unless I want to go in and dig deep and spend days and weeks learning the full nuances of the C Standard, I won't know what to trust. And even if I go in and try some feature out on my compiler to see what happens as by demonstrable example, then I still don't know if it will work when I switch to another compiler, not without the comprehensive learning curve of what's partially defined, and what's not. It's too steep. And things should be naturally intuitive ... at least in 2015 when C's been around for decades. I could understand there being oddities in the early years. The thing's new. People are still finding their footing. But over time... everything should be very straight-forward within the "spirit of C." I find the C Standard very annoying. If I have the opportunity to write a standards document in the future, I will do everything by source code example as a dominant contributor, rather than words, using words only to narrate what is seen in the source code. That way people can expect to see in their code what they see in the documentation, being also able to find examples by searching through the document for some regexp which looks like their own code. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-04 15:34 +0100 |
| Message-ID | <87k2r2n1mb.fsf@bsb.me.uk> |
| In reply to | #71803 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Sunday, October 4, 2015 at 8:35:58 AM UTC-4, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> >> > 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." >> >> What an odd reading of that paragraph. > > How's it odd? "C90 did not explicitly require [the result of reading > one member] ... to have anything to do with [a previous write to > another member]..." > > To me it's completely straight-forward that's what he's saying. Yes it is, and it does *not* say that members don't overlap. Even with overlapping members, the result returned *could* have nothing to do with the value last stored in some other member. His point is that C90 should probably have explicitly stated the "reinterpretation" meaning (since that is the intent), rather not saying anything at all about the value returned from such a union access. But, for all that C90 does not say, nothing in Keith's remark means that members don't overlap. (Remember, though, that this is all hypothetical. C90 certainly intended the semantics we all know and love, even if it was not 100% explicit about saying it.) <snip> >> > 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... >> >> That's going to cause some problems in a group like this. I would urge >> you to use another English phrase. > > I don't place much emphasis on the C Standard phrases because most > people who come here (myself included) aren't experts in the C Standard, > and have no desire to become experts. But you can help them learn by avoiding the misuse of technical terms and by using other plain English ones instead. Since you now know that undefined behaviour has a well-defined technical meaning, I can't see any reason at all (other than wilful obfuscation) to keep using it to mean anything else. > What they desire to know is how > things work in normal English words, and not C Standard words. That's a strong argument for not using C Standard terms, isn't it? Because UB is both normal English and C Stanadardese, the only way to not use C Standard words is to pick some other normal English phrase. I fully expect you will ignore this advice. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-04 08:07 -0700 |
| Message-ID | <3217f0d2-8914-4912-be6e-484766c36285@googlegroups.com> |
| In reply to | #71811 |
On Sunday, October 4, 2015 at 10:35:00 AM UTC-4, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > > On Sunday, October 4, 2015 at 8:35:58 AM UTC-4, Ben Bacarisse wrote: > >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > >> > >> > 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." > >> > >> What an odd reading of that paragraph. > > > > How's it odd? "C90 did not explicitly require [the result of reading > > one member] ... to have anything to do with [a previous write to > > another member]..." > > > > To me it's completely straight-forward that's what he's saying. > > Yes it is, and it does *not* say that members don't overlap. Even with > overlapping members, the result returned *could* have nothing to do with > the value last stored in some other member. His point is that C90 > should probably have explicitly stated the "reinterpretation" meaning > (since that is the intent), rather not saying anything at all about the > value returned from such a union access. But, for all that C90 does not > say, nothing in Keith's remark means that members don't overlap. > > (Remember, though, that this is all hypothetical. C90 certainly > intended the semantics we all know and love, even if it was not 100% > explicit about saying it.) > > <snip> > >> > 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... > >> > >> That's going to cause some problems in a group like this. I would urge > >> you to use another English phrase. > > > > I don't place much emphasis on the C Standard phrases because most > > people who come here (myself included) aren't experts in the C Standard, > > and have no desire to become experts. > > But you can help them learn by avoiding the misuse of technical terms > and by using other plain English ones instead. Since you now know that > undefined behaviour has a well-defined technical meaning, I can't see > any reason at all (other than wilful obfuscation) to keep using it to > mean anything else. > > > What they desire to know is how > > things work in normal English words, and not C Standard words. > > That's a strong argument for not using C Standard terms, isn't it? > Because UB is both normal English and C Stanadardese, the only way to > not use C Standard words is to pick some other normal English phrase. I > fully expect you will ignore this advice. I continue to keep you in my prayers, Ben. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-04 14:42 +0000 |
| Message-ID | <murdt1$o36$1@speranza.aioe.org> |
| In reply to | #71798 |
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> 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 *. (snip) >> 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." > What an odd reading of that paragraph. Anyway, C90 does not permit > non-overlapping union members. Pointers to all union members must > compare equal (when suitably converted). That is a different question. I believe it is possible to make pointers that compare equal, even though the actual data doesn't overlap. It does complicate pointers just a little, though. While the usual C pointer is just an address, that isn't required. -- glen
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-04 15:37 +0000 |
| Message-ID | <5611447c.6325171@news.xs4all.nl> |
| In reply to | #71813 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> > What an odd reading of that paragraph. Anyway, C90 does not permit
> > non-overlapping union members. Pointers to all union members must
> > compare equal (when suitably converted).
>
> That is a different question.
>
> I believe it is possible to make pointers that compare equal,
> even though the actual data doesn't overlap. It does complicate
> pointers just a little, though.
>
> While the usual C pointer is just an address, that isn't required.
Precisely.
Also, padding bits are allowed to be positioned at the
address-"physical" _start_ of the object, not just the end.
IOW, it's allowed for both float and int to take four bytes and take two
padding bytes. (For example, if the natural size of an object on the
Arawak Mynah is four bytes, but the implementor, for some perverse
reason of backarse compatibility, wants them both to be the same size as
on the Arawak 2.7.)
It is, then, equally legal for both of them to be four-byte-aligned,
with the padding bytes for int to be at the rear end of the object and
those for float to be at the start; or, in fact, on the Mynah, the other
way 'round! If you declare this:
union zibble {
float alpha;
int beta;
}
the memory layout will be AABB, where the whole union will take four
bytes, all these unions will be aligned on four-byte boundaries (as will
individual ints and floats), _but_ bytes AA will be used for alpha, and
BB for beta. Assigning anything to alpha will either clobber beta into
random bits _or_ leave it alone, depending on optimisation settings, and
/vice versa/.
If you'd added a member double (or long) gamma, then gamma would have
taken all four bytes, and your comment would have been completely
correct. But only for gamma and either other member; alpha and beta
would still have been mutually independent.
(Oh, and since floating point types are allowed to have trap values,
this _could_ cause undefined behaviour after all...)
Richard
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-05 00:33 +0100 |
| Message-ID | <87eghaky4c.fsf@bsb.me.uk> |
| In reply to | #71818 |
raltbos@xs4all.nl (Richard Bos) writes: > glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > >> > What an odd reading of that paragraph. Anyway, C90 does not permit >> > non-overlapping union members. Pointers to all union members must >> > compare equal (when suitably converted). >> >> That is a different question. >> >> I believe it is possible to make pointers that compare equal, >> even though the actual data doesn't overlap. It does complicate >> pointers just a little, though. >> >> While the usual C pointer is just an address, that isn't required. > > Precisely. > > Also, padding bits are allowed to be positioned at the > address-"physical" _start_ of the object, not just the end. > > IOW, it's allowed for both float and int to take four bytes and take two > padding bytes. <snip> > It is, then, equally legal for both of them to be four-byte-aligned, > with the padding bytes for int to be at the rear end of the object and > those for float to be at the start; Thus the objects overlap. The object includes the padding bits. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-14 10:20 +0000 |
| Message-ID | <561e2bdc.3123562@news.xs4all.nl> |
| In reply to | #71898 |
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > raltbos@xs4all.nl (Richard Bos) writes: > > > glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > > > >> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > > > >> > What an odd reading of that paragraph. Anyway, C90 does not permit > >> > non-overlapping union members. Pointers to all union members must > >> > compare equal (when suitably converted). > >> > >> That is a different question. > >> > >> I believe it is possible to make pointers that compare equal, > >> even though the actual data doesn't overlap. It does complicate > >> pointers just a little, though. > > It is, then, equally legal for both of them to be four-byte-aligned, > > with the padding bytes for int to be at the rear end of the object and > > those for float to be at the start; > > Thus the objects overlap. The object includes the padding bits. Objects, yes. Actual data, no. For union punning to work, the _data_ bits must overlap, and overlap reliably - and the Standard doesn't guarantee that, only that the pointers point at the same addresses. Data bits may overlap padding bits and vice versa. Richard
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-14 13:55 +0100 |
| Message-ID | <87si5da9u6.fsf@bsb.me.uk> |
| In reply to | #72814 |
raltbos@xs4all.nl (Richard Bos) writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > >> raltbos@xs4all.nl (Richard Bos) writes: >> >> > glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >> > >> >> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >> > >> >> > What an odd reading of that paragraph. Anyway, C90 does not permit >> >> > non-overlapping union members. Pointers to all union members must >> >> > compare equal (when suitably converted). >> >> >> >> That is a different question. >> >> >> >> I believe it is possible to make pointers that compare equal, >> >> even though the actual data doesn't overlap. It does complicate >> >> pointers just a little, though. > >> > It is, then, equally legal for both of them to be four-byte-aligned, >> > with the padding bytes for int to be at the rear end of the object and >> > those for float to be at the start; >> >> Thus the objects overlap. The object includes the padding bits. > > Objects, yes. Actual data, no. For union punning to work, the _data_ > bits must overlap, and overlap reliably - and the Standard doesn't > guarantee that, only that the pointers point at the same addresses. > Data bits may overlap padding bits and vice versa. That's why the type punning works. You must get the padding bits or it's not type punning. The standard is clear that what goes by the term is a re-interpretation of the bits of an object -- all the bit of the object. And the object overlap, even if none of their value bits do. You might want to say that it's "not working" in those cases but it's exactly what I'd want to happen, and exactly what the standard says will happen. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-04 22:06 -0700 |
| Message-ID | <kfnbncd6h0b.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71818 |
raltbos@xs4all.nl (Richard Bos) writes:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>>> What an odd reading of that paragraph. Anyway, C90 does not permit
>>> non-overlapping union members. Pointers to all union members must
>>> compare equal (when suitably converted).
>>
>> That is a different question.
>>
>> I believe it is possible to make pointers that compare equal,
>> even though the actual data doesn't overlap. It does complicate
>> pointers just a little, though.
>>
>> While the usual C pointer is just an address, that isn't required.
>
> Precisely.
>
> Also, padding bits are allowed to be positioned at the
> address-"physical" _start_ of the object, not just the end.
>
> IOW, it's allowed for both float and int to take four bytes and take two
> padding bytes. (For example, if the natural size of an object on the
> Arawak Mynah is four bytes, but the implementor, for some perverse
> reason of backarse compatibility, wants them both to be the same size as
> on the Arawak 2.7.)
> It is, then, equally legal for both of them to be four-byte-aligned,
> with the padding bytes for int to be at the rear end of the object and
> those for float to be at the start; or, in fact, on the Mynah, the other
> way 'round! If you declare this:
>
> union zibble {
> float alpha;
> int beta;
> }
>
> the memory layout will be AABB, where the whole union will take four
> bytes, all these unions will be aligned on four-byte boundaries (as will
> individual ints and floats), _but_ bytes AA will be used for alpha, and
> BB for beta. Assigning anything to alpha will either clobber beta into
> random bits _or_ leave it alone, depending on optimisation settings, and
> /vice versa/.
The last part here isn't right. Assigning to alpha must store
all four bytes of alpha. It's true that if an operation is done,
what values any padding bits take on may be determined more or
less arbitrarily. If, however, it's just a straight assignment,
eg
union zibble z;
float f = 0;
z.alpha = f;
then what goes into z.alpha must be the same bits as are
contained in f. This result follows from the rules of
type conversion, in particular, converting to a compatible
type causes no change to the value _or the representation_
(my emphasis).
(Note that assignement always does a conversion, even when
the types on different sides of the equals are the same.)
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-14 10:30 +0000 |
| Message-ID | <561e2e49.3744281@news.xs4all.nl> |
| In reply to | #71935 |
Tim Rentsch <txr@alumni.caltech.edu> wrote:
> raltbos@xs4all.nl (Richard Bos) writes:
>
> > It is, then, equally legal for both of them to be four-byte-aligned,
> > with the padding bytes for int to be at the rear end of the object and
> > those for float to be at the start; or, in fact, on the Mynah, the other
> > way 'round! If you declare this:
> >
> > union zibble {
> > float alpha;
> > int beta;
> > }
> >
> > the memory layout will be AABB, where the whole union will take four
> > bytes, all these unions will be aligned on four-byte boundaries (as will
> > individual ints and floats), _but_ bytes AA will be used for alpha, and
> > BB for beta. Assigning anything to alpha will either clobber beta into
> > random bits _or_ leave it alone, depending on optimisation settings, and
> > /vice versa/.
>
> The last part here isn't right. Assigning to alpha must store
> all four bytes of alpha. It's true that if an operation is done,
> what values any padding bits take on may be determined more or
> less arbitrarily. If, however, it's just a straight assignment,
> eg
>
> union zibble z;
> float f = 0;
> z.alpha = f;
>
> then what goes into z.alpha must be the same bits as are
> contained in f. This result follows from the rules of
> type conversion, in particular, converting to a compatible
> type causes no change to the value _or the representation_
> (my emphasis).
That would imply that all padding bits are required to be trap bits,
which I really don't think is the case. I think the mistake is in the
final clause; I don't think padding bits count as part of "the
representation", in this case at least.
Richard
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-14 08:39 -0700 |
| Message-ID | <lna8rla28s.fsf@kst-u.example.com> |
| In reply to | #72817 |
raltbos@xs4all.nl (Richard Bos) writes:
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>
>> raltbos@xs4all.nl (Richard Bos) writes:
>>
>> > It is, then, equally legal for both of them to be four-byte-aligned,
>> > with the padding bytes for int to be at the rear end of the object and
>> > those for float to be at the start; or, in fact, on the Mynah, the other
>> > way 'round! If you declare this:
>> >
>> > union zibble {
>> > float alpha;
>> > int beta;
>> > }
>> >
>> > the memory layout will be AABB, where the whole union will take four
>> > bytes, all these unions will be aligned on four-byte boundaries (as will
>> > individual ints and floats), _but_ bytes AA will be used for alpha, and
>> > BB for beta. Assigning anything to alpha will either clobber beta into
>> > random bits _or_ leave it alone, depending on optimisation settings, and
>> > /vice versa/.
>>
>> The last part here isn't right. Assigning to alpha must store
>> all four bytes of alpha. It's true that if an operation is done,
>> what values any padding bits take on may be determined more or
>> less arbitrarily. If, however, it's just a straight assignment,
>> eg
>>
>> union zibble z;
>> float f = 0;
>> z.alpha = f;
>>
>> then what goes into z.alpha must be the same bits as are
>> contained in f. This result follows from the rules of
>> type conversion, in particular, converting to a compatible
>> type causes no change to the value _or the representation_
>> (my emphasis).
>
> That would imply that all padding bits are required to be trap bits,
> which I really don't think is the case.
I don't see how that follows.
> I think the mistake is in the
> final clause; I don't think padding bits count as part of "the
> representation", in this case at least.
Strictly speaking, floating-point types don't have "padding bits".
Padding bits are defined only for integers -- because the standard
doesn't say enough about floating-point or pointer representations
for the concept to be necessary. The representations of
floating-point and pointer types are entirely implementation-defined.
For integer types, the padding bits are definitely part of the
representation. For non-integer types, the representation consists
of all sizeof(the_type) bytes of the object.
I seem to recall that an assignment can normalize the representation
of the assigned value. For example, if float has two representations
for 0.0, then
x = 0.0;
can store either of them. The standard's description of assignment
discusses values; it doesn't mention representations.
But if that's the case, then I'm not sure that the requirement that
conversion between compatible types doesn't change the representation
is meaningful.
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-14 23:47 +0000 |
| Message-ID | <mvmpj0$86a$1@speranza.aioe.org> |
| In reply to | #72849 |
Keith Thompson <kst-u@mib.org> wrote: (snip) > Strictly speaking, floating-point types don't have "padding bits". > Padding bits are defined only for integers -- because the standard > doesn't say enough about floating-point or pointer representations > for the concept to be necessary. The representations of > floating-point and pointer types are entirely implementation-defined. > For integer types, the padding bits are definitely part of the > representation. For non-integer types, the representation consists > of all sizeof(the_type) bytes of the object. If there were additional bits not needed by the hardware, then some people might call them padding bits, but it seems that C doesn't. > I seem to recall that an assignment can normalize the representation > of the assigned value. For example, if float has two representations > for 0.0, then > x = 0.0; > can store either of them. The standard's description of assignment > discusses values; it doesn't mention representations. I presume, though, that == still has to compare them equal. Many floating point represenations have a -0.0. It seems that IEEE 754 has some requirements for those formats, with some operations that should generate -0.0. Also, some formats allow for unnormalized representations, which again should compare equal. > But if that's the case, then I'm not sure that the requirement that > conversion between compatible types doesn't change the representation > is meaningful. -- glen
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-15 10:20 -0700 |
| Message-ID | <537dc231-7dc2-4ecb-8d55-4d847c9e8e0c@googlegroups.com> |
| In reply to | #72892 |
On Wednesday, October 14, 2015 at 6:47:58 PM UTC-5, glen herrmannsfeldt wrote: > If there were additional bits not needed by the hardware, then > some people might call them padding bits, but it seems that C doesn't. The term "padding bits" is used to refer to bits that are visible in the numeric value of a "char" representation. It would be possible for hardware to have bits which are ignored when reporting the numeric value of a char representation, but the Standard requires that the defined behavior of a program cannot depend upon the contents of unreported bits. While this guarantee is in many cases, useful, it disallows C implementations which could otherwise be useful for running programs which could get by with a weaker requirement, e.g. that "memcpy" or "memmove" could be used to copy an entire variable at once. While an implementation where semantics were limited in such fashion would be incapable of doing some things that are otherwise possible **and as a consequence, I would advocate that implementations which implement such a restriction should be required to report it, so that code which requires broader semantics could validate that they will be supported** a VM which implemented such a restriction could guarantee 100% reliable protection against the formation of invalid pointers, since there would be no way to form something that looked like a pointer (including the hidden bits) except through the use of legitimate pointer operations.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-15 11:10 -0700 |
| Message-ID | <lnlhb46m0h.fsf@kst-u.example.com> |
| In reply to | #72963 |
supercat@casperkitty.com writes:
> On Wednesday, October 14, 2015 at 6:47:58 PM UTC-5, glen herrmannsfeldt wrote:
>> If there were additional bits not needed by the hardware, then
>> some people might call them padding bits, but it seems that C doesn't.
>
> The term "padding bits" is used to refer to bits that are visible in the
> numeric value of a "char" representation.
I think you mean unsigned char. That's how the standard defines object
representation, and it avoids confusion when plain char is signed and
has two distinct representations for 0.
> It would be possible for hardware
> to have bits which are ignored when reporting the numeric value of a char
> representation, but the Standard requires that the defined behavior of a
> program cannot depend upon the contents of unreported bits.
The character types are not allowed to have padding bits. If an
unsigned char object has some extra bits associated with it that do not
contribute to its value (perhaps a hardware parity bit?), then those
bits would not be visible from C code, and as far as C is concerned they
effectively would not exist.
[...]
--
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-15 12:11 -0700 |
| Message-ID | <08a4e43a-4667-461a-8898-31f96117c74d@googlegroups.com> |
| In reply to | #72972 |
On Thursday, October 15, 2015 at 1:10:32 PM UTC-5, Keith Thompson wrote: > The character types are not allowed to have padding bits. If an > unsigned char object has some extra bits associated with it that do not > contribute to its value (perhaps a hardware parity bit?), then those > bits would not be visible from C code, and as far as C is concerned they > effectively would not exist. It would be legitimate, under the C Standard, for an implementation to use extra bits to keep track of the type of lvalue that was used to write each byte of memory and trap on any attempt to read as any particular type a value that was not written with a compatible type or a char type. For any given combination of visible bit values, there could only be one legal state, but an implementation could use invisible bit values to distinguish each legal state from various illegal states.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-15 12:35 -0700 |
| Message-ID | <29db6d81-16ae-4f18-9a3a-ac290b823144@googlegroups.com> |
| In reply to | #72972 |
On Thursday, October 15, 2015 at 1:10:32 PM UTC-5, Keith Thompson wrote: > I think you mean unsigned char. That's how the standard defines object > representation, and it avoids confusion when plain char is signed and > has two distinct representations for 0. Out of curiosity, do you know to whether there were any significant number of implementations (or, for that matter, any implementations at all) where given "char *p1,*p2", the code "*p1=*p2" would not copy the state of *p2 to *p1 in all cases? Certainly I would not be surprised if there were implementations where the code would not copy all state values if the type "signed char" were used, but I wonder how many implementations there are that meet *NONE* of the following criteria: - Signed character types use two's-complement representation - Default character type is unsigned - Copying a signed value without performing any arithmetic on it will write positive zero if the source contained positive zero, and negative zero if the source contained negative zero. IMHO, discourse could be improved if there were a concise term to refer to a type which can hold the contents of any byte, independent of the numeric interpretation thereof. The phrase "unsigned char" is more than twice as long as "char" and gets quickly cumbersome.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-15 13:52 -0700 |
| Message-ID | <lnd1wf7t37.fsf@kst-u.example.com> |
| In reply to | #72983 |
supercat@casperkitty.com writes:
> On Thursday, October 15, 2015 at 1:10:32 PM UTC-5, Keith Thompson wrote:
>> I think you mean unsigned char. That's how the standard defines object
>> representation, and it avoids confusion when plain char is signed and
>> has two distinct representations for 0.
>
> Out of curiosity, do you know to whether there were any significant number
> of implementations (or, for that matter, any implementations at all) where
> given "char *p1,*p2", the code "*p1=*p2" would not copy the state of *p2 to
> *p1 in all cases?
None that I know of (assuming that p1 and p2 point to char objects).
But if *p2 contains a representation of 0 with the sign bit set (on a
one's-complement system), I wouldn't be surprised if the assignment
cleared the sign bit. Or perhaps the language rules require the
representation to be copied -- but just by using "unsigned char" rather
than "char" I don't have to worry about it.
> Certainly I would not be surprised if there were implementations where the
> code would not copy all state values if the type "signed char" were used,
> but I wonder how many implementations there are that meet *NONE* of the
> following criteria:
>
> - Signed character types use two's-complement representation
>
> - Default character type is unsigned
>
> - Copying a signed value without performing any arithmetic on it will
> write positive zero if the source contained positive zero, and negative
> zero if the source contained negative zero.
>
> IMHO, discourse could be improved if there were a concise term to refer to
> a type which can hold the contents of any byte, independent of the numeric
> interpretation thereof. The phrase "unsigned char" is more than twice as
> long as "char" and gets quickly cumbersome.
IMNSHO, discourse about C is improved by using terms defined by the
standard with their proper meanings. The word "char" has well defined
meaning, and it's not the way you want to use it.
If I were inventing a new C-like language, I'd probably call the type
corresponding to C's "unsigned char" "byte". But I'm not (feel free to
breathe a sign of relief).
Compare the length of "unsigned " with the amount of time and text
you've expended complaining that it's too long.
--
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-15 14:35 -0700 |
| Message-ID | <839bc0ff-6090-4171-956b-10cd0db49129@googlegroups.com> |
| In reply to | #72990 |
On Thursday, October 15, 2015 at 3:52:23 PM UTC-5, Keith Thompson wrote: > IMNSHO, discourse about C is improved by using terms defined by the > standard with their proper meanings. The word "char" has well defined > meaning, and it's not the way you want to use it. In my particular example, I deliberately specified values which would be bit-for-bit identical whether represented as char, signed char, or unsigned char, regardless of the length of that type. With regard to my broader question about copying as "char", I think that if there are no existing implementations where "char" and "unsigned char" do not have equivalent representations it would be useful to make the equivalence of such representations part of the Standard; while I have no problem acknowledging sign/magnitude and ones'-complement implementations that exist, I see no reason it should cater to variations that don't exist and never will. Presently, "uint8_t" gets overloaded both as the type that programs use when blindly copying data, and as the type that they use for compactly storing values 0-255, and programmers avoid typing "unsigned char" when they can avoid it. It would be useful if C were to include a compiler directive which would specify that a compiler could assume variables of types "uint8_t" and "int8_t" won't alias, but for that to be useful there must be some other type which can. Type "char" was the first type ever to be used for that purpose, and if it's guaranteed to be suitable it would seem like it would still be the logical choice. > Compare the length of "unsigned " with the amount of time and text > you've expended complaining that it's too long. Given how many zillion times the phrase "unsigned char" has been written, coming up with a shorter alternative would save people a lot of typing now and forever.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-15 15:51 -0700 |
| Message-ID | <ln8u737njv.fsf@kst-u.example.com> |
| In reply to | #72993 |
supercat@casperkitty.com writes:
> On Thursday, October 15, 2015 at 3:52:23 PM UTC-5, Keith Thompson wrote:
>> IMNSHO, discourse about C is improved by using terms defined by the
>> standard with their proper meanings. The word "char" has well defined
>> meaning, and it's not the way you want to use it.
>
> In my particular example, I deliberately specified values which would be
> bit-for-bit identical whether represented as char, signed char, or unsigned
> char, regardless of the length of that type.
Did you? I just took a quick look upthread, and I didn't see that. But
in any case, that's one more complication that's neatly avoided by using
unsigned char.
> With regard to my broader question about copying as "char", I think
> that if there are no existing implementations where "char" and
> "unsigned char" do not have equivalent representations it would be
> useful to make the equivalence of such representations part of the
> Standard; while I have no problem acknowledging sign/magnitude and
> ones'-complement implementations that exist, I see no reason it should
> cater to variations that don't exist and never will.
If char is unsigned, then it has exactly the same range and
representation as unsigned char. If char is signed, then negative
values have no representation as unsigned char, and unsigned char values
greater than CHAR_MAX hae no representation as char, so it's not
possible for char and unsigned char to have "equivalent
representations". (Unless you have your own definition of the phrase
"equivalent representations", which I suspect you do.)
> Presently, "uint8_t" gets overloaded both as the type that programs use
> when blindly copying data, and as the type that they use for compactly
> storing values 0-255, and programmers avoid typing "unsigned char" when
> they can avoid it.
Hmm? I certainly don't avoid typing "unsigned char". I'm not aware
that other programmers do either. I'll use uint8_t if I want to
explicitly assume 8-bit bytes; otherwise I'll use unsigned char to refer
to raw memory.
> It would be useful if C were to include a compiler
> directive which would specify that a compiler could assume variables of
> types "uint8_t" and "int8_t" won't alias, but for that to be useful
> there must be some other type which can. Type "char" was the first type
> ever to be used for that purpose, and if it's guaranteed to be suitable
> it would seem like it would still be the logical choice.
The standard defines "object representation" in terms of unsigned char.
The behavior of the functions in <string.h> is defined in terms of
unsigned char (N1570 7.24.1p3), which guarantees that every possible
object representation is valid and has a unique value.
>> Compare the length of "unsigned " with the amount of time and text
>> you've expended complaining that it's too long.
>
> Given how many zillion times the phrase "unsigned char" has been written,
> coming up with a shorter alternative would save people a lot of typing
> now and forever.
I wasn't entirely serious about the cost comparison. The cost of typing
"unsigned char" vs. "char" is trivial, and it has the considerable
virtue of being correct.
--
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-16 06:48 -0700 |
| Message-ID | <a6485b2d-c8df-429c-a5bf-3eafe0885966@googlegroups.com> |
| In reply to | #72997 |
On Thursday, October 15, 2015 at 5:51:56 PM UTC-5, Keith Thompson wrote: > If char is unsigned, then it has exactly the same range and > representation as unsigned char. If char is signed, then negative > values have no representation as unsigned char, and unsigned char values > greater than CHAR_MAX hae no representation as char, so it's not > possible for char and unsigned char to have "equivalent > > representations". (Unless you have your own definition of the phrase > "equivalent representations", which I suspect you do.) In all systems, conversion of a negative value to an unsigined value of the same type yields the value which, when adding the inverse of that negative value, yields the original. In other words, signed-to-unsigned conversions are specified in a fashion independent of representation. In a two's-complement system, this conversion is representation-preserving. In other systems, it is not. In C as envisioned by K&R, there was no question but that every object had a unique representation in "char" because there *was* no "unsigned char". C89 relaxed this by allowing for the possibility of implementations where "char" as a signed type with a non-two's-complement representation but I don't know whether any such platforms existed. If none have ever existed, I don't see much point in continuing to allow for them. > Hmm? I certainly don't avoid typing "unsigned char". I'm not aware > that other programmers do either. I'll use uint8_t if I want to > explicitly assume 8-bit bytes; otherwise I'll use unsigned char to refer > to raw memory. I see a lot of code using "uint8_t".
[toc] | [prev] | [next] | [standalone]
Page 5 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