Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: bit value of a negative number |
| Date | 2016-07-30 09:38 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <nniald$65o$1@dont-email.me> (permalink) |
| References | <159d5df7-d640-40b1-9866-2bb16d7769ee@googlegroups.com> <87a8gzxv8b.fsf@bsb.me.uk> <punning-20160730120244@ram.dialup.fu-berlin.de> |
On 07/30/2016 07:31 AM, Stefan Ram wrote: ... > I think the old recommendation for pointer type punning Pointer type punning can violate the anti-aliasing rules; using unions is safer, not less safe. > stems from a misunderstanding of a phrase in the standard: > > 6.2.6.1p7 in 2016: > > �When a value is stored in a member of an object of > union type, the bytes of the object representation that > do not correspond to that member but do correspond to > other members take unspecified values.� > > It seems that in my program above, there are no bytes that > correspond to one member but not to the other, so that the > conclusion of this sentence does not apply. > > But some people read the sentence quoted above superficially > and take it to mean that the other members take undefined > values. Possibly that was the reason they recommended me to > prefer pointer type punning 15 years ago. As I remember, the fact that it was technically problematic was due to an explicit statement to that effect in the C90 standard: reading the value of a member of a union that was not the same as the one last written to was problematic in some way - but I don't have a copy of C90 that I can reference to confirm that. The relevant clause should be in the semantics section of the description of the member selection operator. > Still, I have not yet read a sentence in the standard that > says which values the other members /do/ take, when a value > is stored in one member (assuming - for simplicity that all > members have the same size). Since this can differ between > implementations, it might be /unspecified/ too. It is. > Of, course, the naive assumption is that there is a mapping > from values of a type to bit sequences of the length > sizeof( T )*CHAR_BIT. When I call this mapping B( T ) and its > inverse V( T ), then we assume that type punning from type T > to type S give > > V( S )( B( T )( v )) Since C99, the standard now describes the behavior in terms of reinterpretation of the bits, which is basically what you've just described. However, it does so in a footnote rather than in the normative text. That's only supposed to happen if that is a conclusion which can be rigorously derived from the normative text, but I'm not sure of that derivation. In any event, it's also what essentially every real implementation did even before the wording was changed.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
bit value of a negative number sinbad <sinbad.sinbad@gmail.com> - 2016-07-30 02:38 -0700
Re: bit value of a negative number Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-30 02:50 -0700
Re: bit value of a negative number Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-30 11:42 +0100
Re: bit value of a negative number James Kuyper <jameskuyper@verizon.net> - 2016-07-30 09:38 -0400
Re: bit value of a negative number "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-30 11:39 -0400
Re: bit value of a negative number Keith Thompson <kst-u@mib.org> - 2016-07-30 13:59 -0700
Re: bit value of a negative number Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-30 15:16 +0100
Re: bit value of a negative number Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 06:31 -0700
Re: bit value of a negative number Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-31 17:28 +0100
Re: bit value of a negative number supercat@casperkitty.com - 2016-07-31 13:19 -0700
Re: bit value of a negative number Ike Naar <ike@iceland.freeshell.org> - 2016-07-31 20:46 +0000
Re: bit value of a negative number Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-30 14:21 -0700
Re: bit value of a negative number supercat@casperkitty.com - 2016-07-31 13:37 -0700
Re: bit value of a negative number Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 16:59 -0700
Re: bit value of a negative number supercat@casperkitty.com - 2016-07-31 12:56 -0700
Re: bit value of a negative number Barry Schwarz <schwarzb@dqel.com> - 2016-07-30 10:15 -0700
Re: bit value of a negative number Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-30 10:25 -0700
csiph-web