Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| 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> |
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
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