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


Groups > comp.lang.c > #91355

Re: bit value of a negative number

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>

Show all headers | View raw


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


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