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