Representation of NULL and 0.0 (was Re: Zero Length Arrays ...)

T. William Wells bill at twwells.com
Mon Dec 18 04:58:35 AEST 1989


In article <545 at mwtech.UUCP> martin at mwtech.UUCP (Martin Weitzel) writes:
: >Warning: null pointers and floating point zeros are *not*
: >necessarily represented by bit patterns of all zero bits.
:
: Sorry, my copy of the draft is not the most recent (we Europeans
: seem to have no easy way, to get an up-to-date *A*NSI-Standard :-/),

Actually, most everyone gets it the same way: by calling someone
(is Global Engineering the only one?) and ordering a copy. It has
been just as difficult for us U.S.*A*mericans to get an up to date
standard.

: If the type of "a" would have been int or long, one could ommit
: the initialization loop and replace malloc with calloc, which may
: have a faster way to zero the allocated space. (Am I right so far?)

Yes. Also for short or char.

: Wouldn't it have been wise to add another 'calloc' for floating
: types and NULL pointers, as the initializing feature of calloc
: is weak in this respect? (As an aside, the pure existance of
: such a function would have warned all programmers, who are still
: in believe, they allways receive NULL-pointers or 0.0 from calloc).

Maybe. I'm of the opinion that calloc should simply go away. I
never use it.

: Now, how is the situation with statically allocated data (esp.
: not fully initialized arrays). The compiler 'knows' the exact
: data type in this situation (other than calloc in the above example)
: and could use 'the right' representation. What are the guarantees
: of the standard: zero bits or NULL resp. 0.0?

NULL or 0.0. The one case I didn't see covered was the initial
value of a union. It appears that the union is initialized as if
its first element were initialized, but I didn't see it say this
explicitly.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill at twwells.com



More information about the Comp.lang.c mailing list