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

Henry Spencer henry at utzoo.uucp
Sun Dec 17 14:35:27 AEST 1989


In article <545 at mwtech.UUCP> martin at mwtech.UUCP (Martin Weitzel) writes:
>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?)

That's correct; integer data types are pretty much constrained to have
the obvious binary representation.  However, a malloc() followed by a
memset() is unlikely to be any slower than calloc().

>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?...

What would you do about structs?  The very existence of calloc is
basically a botch.  It only works for a few data types, and there
is no way to build a more general version.

>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?

Static initialization is guaranteed to happen as if by assignment of 0.
On a system where some datatypes do not use all-zero-bits for 0, the
compiler is going to have to work harder.
-- 
1755 EST, Dec 14, 1972:  human |     Henry Spencer at U of Toronto Zoology
exploration of space terminates| uunet!attcan!utzoo!henry henry at zoo.toronto.edu



More information about the Comp.lang.c mailing list