Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Representation of NULL and 0.0 (was Re: Zero Length Arrays ...)
Message-ID: <1989Dec17.033527.2738@utzoo.uucp>
Organization: U of Toronto Zoology
References: <2298@jato.Jpl.Nasa.Gov> <11715@smoke.BRL.MIL> <480@codonics.COM> <1989Dec2.210042.12668@twwells.com> <8129@cg-atla.UUCP> <1989 <545@mwtech.UUCP>
Date: Sun, 17 Dec 89 03:35:27 GMT

In article <545@mwtech.UUCP> martin@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@zoo.toronto.edu