Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #91362

Re: bit value of a negative number

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>

Show all headers | View raw


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


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