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