Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: bit value of a negative number |
| Date | 2016-07-30 11:39 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <f4f991da-b4e8-b84d-5139-e48b025c9fa8@verizon.net> (permalink) |
| References | <159d5df7-d640-40b1-9866-2bb16d7769ee@googlegroups.com> <87a8gzxv8b.fsf@bsb.me.uk> <punning-20160730120244@ram.dialup.fu-berlin.de> <nniald$65o$1@dont-email.me> <unions-20160730145731@ram.dialup.fu-berlin.de> |
On 07/30/2016 09:59 AM, Stefan Ram wrote: > James Kuyper <jameskuyper@verizon.net> writes: >> 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. > > Quoting from an old draft, from possibly 1988 or 1989 > (3.3.2.3, Semantics, p3): > > »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.«. > > »Implementation-defined«, however, might be the best one can > hope for anyways, even today. Not quite. The C standard says "Except for bit-fields, objects are composed of contiguous sequences of one or more bytes, the number, order, and encoding of which are either explicitly specified or implementation-defined." Assuming that footnote 95 correctly describes something that's guaranteed by the normative text, it's possible to use the implementation-defined encoding to determine precisely what the result of reinterpreting the bits would be. Under C90, the clause cited above gave the implementation the freedom to define it as having a result different from that which could be inferred from a knowledge of the encoding. I can't imagine any good reason for doing so, and I doubt that any implementation actually did so (which is why the C99 wording could be changed in this fashion without causing problems) but it was permitted. >> 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. > > Yes, »6.5.2.3 Structure and union members« in p3 has: > > »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,95)«, and > > »95) 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.«. > > I have not yet found a part in 6.2.6 that gives more > semantics to union punning, though. I agree - but at least one C committee member has claimed that it can be derived from other words somewhere in the standard (a claim that he failed to back up with explicit citations).
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