Path: utzoo!attcan!uunet!husc6!bloom-beacon!athena.mit.edu!scs
From: scs@athena.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: calloc (was: retiring gets(3))
Message-ID: <8057@bloom-beacon.MIT.EDU>
Date: 19 Nov 88 09:02:06 GMT
References: <1988Nov8.054845.23998@utstat.uucp> <7963@bloom-beacon.MIT.EDU> <4509@aldebaran.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 42

In article <4509@aldebaran.UUCP> jimp@cognos.UUCP (Jim Patterson) writes:
>In article <7963@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes:
>>...such a zero fill does not necessarily result in NULL
>>pointers or 0.0 floating-point values,
>I've seen this point made many times...
>Realistically, though, are there REALLY C implementations out there
>which don't take binary 0 to be a NULL pointer...
>
>Where a good implementation of calloc() can shine is in virtual memory
>(VM) environments where it can avoid actually faulting in the pages
>that you allocate.

Realistically, though, how many systems implement calloc()
this way?

>It's worth noting that pre-clearing memory shouldn't be considered
>wasted overhead on the part of the OS. It's an important security
>precaution, to prevent other system users from poking through memory
>that used to belong to someone else and which could contain sensitive
>information. This may not be important to all users, but it is to
>many.

>I don't consider calloc() specious; if you have a large table to
>allocate even memset() can be too much overhead if you can do it
>better. Explicitly setting all elements of a table to the appropriate
>sort of 0, while maximally portable, is definitely even less efficient...

It's worth noting that "maximal portability" shouldn't be
considered wasted overhead on the part of the programmer or
the program.  It's simple prudence: you can't tell how long
a program is going to be around (wouldn't you hope that a
program you've put a lot of work into will enjoy a long and
productive life?), and you can't predict what kinds of
radical architectures may be introduced which will have good
reasons for implementing things differently from
"traditional" machines.

This is unfortunately not important to all programmers, but
it is to some.

                                            Steve Summit
                                            scs@adam.pika.mit.edu