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 | 12 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 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-03 00:38 -0700 |
| Message-ID | <lnoaggz9im.fsf@kst-u.example.com> |
| In reply to | #71651 |
supercat@casperkitty.com writes:
> On Friday, October 2, 2015 at 5:43:49 PM UTC-5, Ben Bacarisse wrote:
[...]
>> 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.
Exactly what new rule are you referring to? Can you cite a section
number in N1256 or N1570?
The phrase "strict aliasing" does not appear in the C99 or C11 standard.
The rule that I think you may be referring to (restricting the kinds of
lvalue that can be used to access an object's value) exists, with some
changes in wording, in all three editions, C90, C99, and C11.
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-02 16:10 -0700 |
| Message-ID | <ln8u7k27g5.fsf@kst-u.example.com> |
| In reply to | #71633 |
supercat@casperkitty.com writes:
[...]
> 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++,
[...]
There were some changes between C90 and C99 (C11 is the same as
C99 in this area).
I recently quoted the relevant footnote from N1570/C11 6.5.2.3:
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.
This footnote is attached to paragraph 3, which says in part:
A postfix expression followed by the . operator and an
identifier designates a member of a structure or union
object. The value is that of the named member, and is an lvalue
if the first expression is an lvalue
The C90 wording is different. It has the same normative wording
I quoted above, but with this additional wording that isn't in C99
or C11:
With one exception, if a member of a union object is accessed after
a value has been stored in a different member of the object, the
behavior is implementation-defined.
(The exception is for common initial sequences, something that's still
in C11.) The footnote says:
The "byte orders" for scalar types are invisible to isolated
programs that do not indulge in type punning (for example, by
assigning to one member of a union and inspecting the storage by
accessing another member that is an appropriately sized array
of character type). but must be accounted for when conforming
to externally imposed storage layouts.
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.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-04 21:54 -0700 |
| Message-ID | <kfnfv1p6hkb.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71650 |
Keith Thompson <kst-u@mib.org> writes:
> supercat@casperkitty.com writes:
> [...]
>> 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++,
>
> [...]
>
> There were some changes between C90 and C99 (C11 is the same as
> C99 in this area).
>
> I recently quoted the relevant footnote from N1570/C11 6.5.2.3:
>
> 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.
>
> This footnote is attached to paragraph 3, which says in part:
>
> A postfix expression followed by the . operator and an
> identifier designates a member of a structure or union
> object. The value is that of the named member, and is an
> lvalue if the first expression is an lvalue
>
> The C90 wording is different. It has the same normative wording I
> quoted above, but with this additional wording that isn't in C99
> or C11:
>
> With one exception, if a member of a union object is accessed
> after a value has been stored in a different member of the
> object, the behavior is implementation-defined.
>
> (The exception is for common initial sequences, something that's
> still in C11.) The footnote says:
>
> The "byte orders" for scalar types are invisible to isolated
> programs that do not indulge in type punning (for example, by
> assigning to one member of a union and inspecting the storage
> by accessing another member that is an appropriately sized
> array of character type). but must be accounted for when
> conforming to externally imposed storage layouts.
>
> 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.
There's a lot of confusion about how union accesses are supposed
to be handled, and made more confusing by these wording changes.
Hopefully the following will shed some light on the matter.
C90 was fairly vague about how different types are represented.
The representation of integer types "shall define values by use
of a pure binary numeration system". The representation of
floating-point types is given as unspecified in normative text,
but listed in Annex G implementation-defined. For most other
types very little is said about what their requirements are in
terms of representation. The description of how union accesses
work in C90 (including the footnote about byte orders) is a tacit
admission that how different types are represented in memory was
meant to be implementation-defined, but C90 never got around to
saying that directly.
In C99 this changed. How different types are represented is
described more thoroughly, and significantly there is a proviso
that the representations of /all/ types is implementation-defined
(to the extent that the Standard didn't define them already).
Thus in the C99 world, the clause about union member access being
implementation-defined is unnecessary. A better term might be
"implementation-determined", like the behavior of bitwise
operators when working on negative numbers - not directly
implmentation-defined, but derivable from other aspects that are.
The phrasing in C99 simply dropped the "implementation-defined"
clause in the section on struct/union access. There is no need
to mention it, since how it has to work can be inferred from the
semantics of lvalue conversion and the C99 requirement that type
representations are, at a minimum, implementation-defined.
A point of historical interest is that C99 did not originally
include the footnote about type punning. There was seemingly no
need to, since (as seen through the eyes of those in the
standards committee), the 'implementation-defined' characteristic
had simply been moved from one part of the Standard to another.
Later though this became an issue, because it wasn't obvious that
the intention was the same all along -- namely, that memory would
simply be re-interpreted at the bit level -- due to the nature of
where the various changes were done in the Standard. To address
this, and to make sure that people understood both what behavior
is required and that the intent is what everyone had been used to
all along, the "type punning" footnote was added in one of the
Technical Corrigenda (IIANM this footnote is present in N1256 but
not in N1124).
To sum up, there are three main points:
1. The semantics of how union member access works is a
consequence of normative text that describes what union
types are and how lvalue conversion works (and assignment,
etc);
2. Because of the requirement that type representation be,
at a minimum, implementation-defined, the behavior of
reading a union member other than the last one written
is determined by implmentation-defined behavior if the
last member written is at least as large as the one
being read; and
3. Historical documents on the open-std.org website show
that the intent all along has been the same, and that the
"type punning" footnote was added precisely to document
that intention.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-05 08:19 -0700 |
| Message-ID | <lnegh95ond.fsf@kst-u.example.com> |
| In reply to | #71934 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> A point of historical interest is that C99 did not originally
> include the footnote about type punning. There was seemingly no
> need to, since (as seen through the eyes of those in the
> standards committee), the 'implementation-defined' characteristic
> had simply been moved from one part of the Standard to another.
> Later though this became an issue, because it wasn't obvious that
> the intention was the same all along -- namely, that memory would
> simply be re-interpreted at the bit level -- due to the nature of
> where the various changes were done in the Standard. To address
> this, and to make sure that people understood both what behavior
> is required and that the intent is what everyone had been used to
> all along, the "type punning" footnote was added in one of the
> Technical Corrigenda (IIANM this footnote is present in N1256 but
> not in N1124).
Correct. The footnote was introduced in TC3 in response to Defect
Report #257.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_257.htm
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-02 15:16 -0700 |
| Message-ID | <lnd1ww29xk.fsf@kst-u.example.com> |
| In reply to | #71612 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> 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.
CHAR_MAX + 1 might not be the best example. Since the operands of "+"
are promoted, the result is perfectly well defined (unless CHAR_MAX is
equal to INT_MAX or to UINT_MAX).
There is a (common?) misconception that accessing a union member other
than the most recently written one has undefined behavior. In fact, a
footnote in N1570 6.5.2.3 says:
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.
This means, for example, that this:
union { int i; unsigned u; } u;
u.i = 42;
printf("%u\n", u.u);
is well-defined and will print 42, since there are specific guarantees
about the representations of corresponding signed and unsigned types.
--
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-02 22:52 +0000 |
| Message-ID | <mun1s2$ort$1@speranza.aioe.org> |
| In reply to | #71646 |
Keith Thompson <kst-u@mib.org> wrote:
(snip)
> CHAR_MAX + 1 might not be the best example. Since the operands of "+"
> are promoted, the result is perfectly well defined (unless CHAR_MAX is
> equal to INT_MAX or to UINT_MAX).
I though that is what was meant, but maybe not.
> There is a (common?) misconception that accessing a union member other
> than the most recently written one has undefined behavior. In fact, a
> footnote in N1570 6.5.2.3 says:
> 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.
> This means, for example, that this:
> union { int i; unsigned u; } u;
> u.i = 42;
> printf("%u\n", u.u);
> is well-defined and will print 42, since there are specific guarantees
> about the representations of corresponding signed and unsigned types.
OK, but for a union of int and float, and assume that
sizeof(int)==sizeof(float) is it requried that a value assigned
to the float give the machine dependent representation of the
floating point value?
More specifically, if you have two unions between int and float,
again with the appropriate sizeof, if you assign the same value
to the two floats, is it required that the two ints have the same
value? If you assign different values to the floats, will the
ints have different values?
Some years ago, I was wondering about the possibility of a C
compiler generating JVM code. That is, compiling similar to the
way it would compile comparable C code. Since Java doesn't have
anything like union, and pretty much disallows type punning, the
most obvious answer was to generate the same as for a struct.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-03 00:48 -0700 |
| Message-ID | <lnk2r4z93d.fsf@kst-u.example.com> |
| In reply to | #71648 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
[...]
>> There is a (common?) misconception that accessing a union member other
>> than the most recently written one has undefined behavior. In fact, a
>> footnote in N1570 6.5.2.3 says:
>
>> 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.
>
>> This means, for example, that this:
>
>> union { int i; unsigned u; } u;
>> u.i = 42;
>> printf("%u\n", u.u);
>
>> is well-defined and will print 42, since there are specific guarantees
>> about the representations of corresponding signed and unsigned types.
>
> OK, but for a union of int and float, and assume that
> sizeof(int)==sizeof(float) is it requried that a value assigned
> to the float give the machine dependent representation of the
> floating point value?
I don't understand. Did you mean to ask about the representation of the
float member after assigning a value to the float member? In that case,
it doesn't matter that it's a member of a union.
> More specifically, if you have two unions between int and float,
> again with the appropriate sizeof, if you assign the same value
> to the two floats, is it required that the two ints have the same
> value?
No, it's possible for a float value to have two different
representations.
> If you assign different values to the floats, will the
> ints have different values?
Not necessarily; an int value may also have two different
representations. For example, one of the float values my map to 0, and
the other to -0.
But if there are no padding bits or trap representations (you can verify
this by checking the values of CHAR_BIT, sizeof (int), INT_MIN, and
INT_MAX), then two distinct float values will map to two different int
values.
> Some years ago, I was wondering about the possibility of a C
> compiler generating JVM code. That is, compiling similar to the
> way it would compile comparable C code. Since Java doesn't have
> anything like union, and pretty much disallows type punning, the
> most obvious answer was to generate the same as for a struct.
The JVM code could create an array of bytes and manipulate it to emulate
C object, but that would probably end up being grossly inefficient.
I don't think you could have a conforming C implementation in which
union members don't overlap.
--
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-03 08:22 +0000 |
| Message-ID | <muo38c$mr9$1@speranza.aioe.org> |
| In reply to | #71660 |
Keith Thompson <kst-u@mib.org> wrote: (snip on type punning and union, then I wrote) >> OK, but for a union of int and float, and assume that >> sizeof(int)==sizeof(float) is it requried that a value assigned >> to the float give the machine dependent representation of the >> floating point value? > I don't understand. Did you mean to ask about the representation of the > float member after assigning a value to the float member? In that case, > it doesn't matter that it's a member of a union. Yes, I meant the value of the int. >> More specifically, if you have two unions between int and float, >> again with the appropriate sizeof, if you assign the same value >> to the two floats, is it required that the two ints have the same >> value? > No, it's possible for a float value to have two different > representations. Well, I meant not including that, but yes that is one to watch. >> If you assign different values to the floats, will the >> ints have different values? > Not necessarily; an int value may also have two different > representations. For example, one of the float values my map to 0, > and the other to -0. > But if there are no padding bits or trap representations (you can verify > this by checking the values of CHAR_BIT, sizeof (int), INT_MIN, and > INT_MAX), then two distinct float values will map to two different int > values. Can unions have padding that isn't padding bits? Maybe not at the beginning, though. >> Some years ago, I was wondering about the possibility of a C >> compiler generating JVM code. That is, compiling similar to the >> way it would compile comparable C code. Since Java doesn't have >> anything like union, and pretty much disallows type punning, the >> most obvious answer was to generate the same as for a struct. > The JVM code could create an array of bytes and manipulate it to emulate > C object, but that would probably end up being grossly inefficient. Someone might have done that, but that isn't what I was thinking about. I wanted more like what someone would expect from a Java compiler compiling comparable Java code. For example, I think memcpy() can figure out what is being copied and copy it appropriately. But union doesn't make it so easy to know what happens and when. > I don't think you could have a conforming C implementation in which > union members don't overlap. Did this change with C99? I thought I got a different answer when I asked years ago, which might have been before C99. Not that it matter so much, I could just say "don't do that". -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-03 12:05 -0700 |
| Message-ID | <lnfv1rzsan.fsf@kst-u.example.com> |
| In reply to | #71661 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
[...]
>> But if there are no padding bits or trap representations (you can verify
>> this by checking the values of CHAR_BIT, sizeof (int), INT_MIN, and
>> INT_MAX), then two distinct float values will map to two different int
>> values.
>
> Can unions have padding that isn't padding bits? Maybe not
> at the beginning, though.
Definitely not at the beginning, but yes, unions can have padding. If
the members are of different sizes, you can think of the memory
following a smaller member as padding, but it's also part of the larger
member. A union can be larger than the largest of its members (for
example, a union of a 1-byte char and a 2-byte short might have a size
of 4 bytes), but that's not relevant if all you're doing is writing and
reading the members.
[...]
>> The JVM code could create an array of bytes and manipulate it to emulate
>> C object, but that would probably end up being grossly inefficient.
>
> Someone might have done that, but that isn't what I was thinking
> about. I wanted more like what someone would expect from a
> Java compiler compiling comparable Java code.
>
> For example, I think memcpy() can figure out what is being copied
> and copy it appropriately. But union doesn't make it so easy to
> know what happens and when.
Perhaps someone could implement a non-conforming C-like language using
the JVM, and it's possible that might be useful. But I don't know
enough about the JVM to say much more.
>> I don't think you could have a conforming C implementation in which
>> union members don't overlap.
>
> Did this change with C99? I thought I got a different answer
> when I asked years ago, which might have been before C99.
>
> Not that it matter so much, I could just say "don't do that".
There was at least a change in the wording, as I posted yesterday
in this thread. In C90, accessing a union member after storing a
value in a different member has implementation-defined behavior.
That sentence is gone in C99 and C11. C99 and C11 explicitly say
(but only in a non-normative footnote) that accessing a non-current
union member uses the reinterpreted object representation; C90
does not.
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-10-03 16:38 -0400 |
| Message-ID | <e1XPx.27102$SU1.5757@fx26.iad> |
| In reply to | #71648 |
On 10/2/15 6:52 PM, glen herrmannsfeldt wrote: > OK, but for a union of int and float, and assume that > sizeof(int)==sizeof(float) is it requried that a value assigned > to the float give the machine dependent representation of the > floating point value? > > More specifically, if you have two unions between int and float, > again with the appropriate sizeof, if you assign the same value > to the two floats, is it required that the two ints have the same > value? If you assign different values to the floats, will the > ints have different values? > It is allowed (in most cases) for a type to have multiple representations for the same value (simplest case is padding bits). The existence of padding bits can mess up your 2nd assertion. As does the existence of trap representations. There are some types which are assured to not have padding bits or trap representations.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-03 00:00 +0100 |
| Message-ID | <87pp0wq3jc.fsf@bsb.me.uk> |
| In reply to | #71646 |
Keith Thompson <kst-u@mib.org> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> 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.
>
> CHAR_MAX + 1 might not be the best example. Since the operands of "+"
> are promoted, the result is perfectly well defined (unless CHAR_MAX is
> equal to INT_MAX or to UINT_MAX).
That was exactly my point! CHAR_MAX + 1 *might* be undefined but
whether it is or not depends on the exact values involved. Similarly a
type punning union access *might* be undefined, but that will be because
the specific value involved makes it so.
But I agree it's not the best example, not only because that point might
be missed, but also because it is implementation defined rather than
unspecified behaviour.
> There is a (common?) misconception that accessing a union member other
> than the most recently written one has undefined behavior. In fact, a
> footnote in N1570 6.5.2.3 says:
>
> 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.
>
> This means, for example, that this:
>
> union { int i; unsigned u; } u;
> u.i = 42;
> printf("%u\n", u.u);
>
> is well-defined and will print 42, since there are specific guarantees
> about the representations of corresponding signed and unsigned types.
Right. That's one of the cases where it is specified. I did make a
point of saying that the standard does not say what result is "in most
cases".
It's also listed in Appendix J1 under Unspecified Behaviour:
-- The values of bytes that correspond to union members other than the
one last stored into (6.2.6.1).
Both that and the footnote are non-normative, but they make the intent
very clear.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-04 22:16 -0700 |
| Message-ID | <kfn7fn16gjg.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71649 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> [...]
>>> 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.
>>
>> CHAR_MAX + 1 might not be the best example. Since the operands of "+"
>> are promoted, the result is perfectly well defined (unless CHAR_MAX is
>> equal to INT_MAX or to UINT_MAX).
>
> That was exactly my point! CHAR_MAX + 1 *might* be undefined but
> whether it is or not depends on the exact values involved. Similarly a
> type punning union access *might* be undefined, but that will be because
> the specific value involved makes it so.
>
> But I agree it's not the best example, not only because that point might
> be missed, but also because it is implementation defined rather than
> unspecified behaviour.
>
>> There is a (common?) misconception that accessing a union member other
>> than the most recently written one has undefined behavior. In fact, a
>> footnote in N1570 6.5.2.3 says:
>>
>> 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.
>>
>> This means, for example, that this:
>>
>> union { int i; unsigned u; } u;
>> u.i = 42;
>> printf("%u\n", u.u);
>>
>> is well-defined and will print 42, since there are specific guarantees
>> about the representations of corresponding signed and unsigned types.
>
> Right. That's one of the cases where it is specified. I did make a
> point of saying that the standard does not say what result is "in most
> cases".
>
> It's also listed in Appendix J1 under Unspecified Behaviour:
>
> -- The values of bytes that correspond to union members other than the
> one last stored into (6.2.6.1).
>
> Both that and the footnote are non-normative, but they make the intent
> very clear.
The item in Annex J.1 is not on point for the example that was
being discussed earlier, where the two members in question are
the same size. The byte values that are unspecified (ie, as part
of that portion of 6.2.6.1) are only those /after/ the member
being stored into.
[toc] | [prev] | [standalone]
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
Back to top | Article view | comp.lang.c
csiph-web