Why NULL is 0
David Keppel
pardo at june.cs.washington.edu
Sat Apr 9 08:37:34 AEST 1988
In article <6594 at bellcore.bellcore.com> sjs at spectral.UUCP (Stan Switzer) writes:
>In reference to:
>> > People (usually ;>) have no problem with the idea the while assigning a
>> > zero to a float gives it the vaule 0.0, in most implementations the
>> > float value does not have all bits set to zero.
>
>And:
>> I do believe IEEE and Vax's version of float is a bit pattern
>> consisting of all zeros. So what are these implementations that don't
>> use zero bit pattern?
[ some machines that use non-0's for 0.0 ]
According to my hardware book [DEC85] the F_floating and D_floating form on
the VAX both represent 0.0 by having the sign and magnitude bits <7:15> zero,
with any mantissa. Similarly the G_floating type is 0.0 when <4:15> are zero
bits and the H_floating type 0.0 when <0:15> are zero bits.
Thus the following are perfectly valid F_floating representations for 0.0:
00 00 00 00
ff ff 00 7f
43 21 00 12
And there are analogs for the other types. This does mean (for the VAX)
that assigning at least 16 bits of zeroes (for F_floating and D_floating)
or 32 bits of zeroes (for G_floating and H_floating) give 0.0, which I think
was the spirit of the original poster. I would like to point out, however,
that it is very much *not* possible to compare bit patterns of a float to
*anything* in 8- 16- or 32- bit quantities and determine whether the value
is 0.0 *except* for the H_floating type (which is 16 bytes long).
[DEC85] VAX ARCHITECTURE REFERENCE MANUAL (c) 1985 Digital Equipment
Corporation, Maynard Massachusetts. Copied without permission.
;-D on ( VAX? What's that? ) Pardo
More information about the Comp.lang.c
mailing list