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


Groups > comp.lang.c > #91401

Re: bit value of a negative number

From Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups comp.lang.c
Subject Re: bit value of a negative number
Date 2016-07-31 17:28 +0100
Organization A noiseless patient Spider
Message-ID <87bn1dwz4r.fsf@bsb.me.uk> (permalink)
References <159d5df7-d640-40b1-9866-2bb16d7769ee@googlegroups.com> <87a8gzxv8b.fsf@bsb.me.uk> <punning-20160730120244@ram.dialup.fu-berlin.de> <8737mrxlbg.fsf@bsb.me.uk> <kfnzioylyrb.fsf@x-alumni2.alumni.caltech.edu>

Show all headers | View raw


Tim Rentsch <txr@alumni.caltech.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>> <snip>
>>
>>>> Often the best way to examine the representation of an object is to
>>>> treat it as a sequence of unsigned char which you can do with a union.
>>>> For any complete object type T you can write
>>>> union { T value; unsigned char byte[sizeof (T)]; } u;
>>>> and, after setting u.value, you can look at u.byte[0] and upwards to see
>>>> the bits that make up the value (including any padding bits).
>
> [...]
>
>>>   I think the old recommendation for pointer type punning
>>>   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.
>>
>> I think each member corresponds to the other and the conclusion does
>> apply.
>
> I don't know what you mean to say here.

Neither do I.  I was misreading it or, to be more accurate, not reading
it in that I think I just assumed I knew what it was saying.

<snip>
-- 
Ben.

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