Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!uw-beaver!uw-entropy!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: FREE
Message-ID: <2353@dataio.Data-IO.COM>
Date: 2 Mar 90 19:14:19 GMT
References: <2714@stl.stc.co.uk> <1990Feb27.155133.20341@druid.uucp> <16055@haddock.ima.isc.com> <1990Mar1.140829.17199@druid.uucp>
Reply-To: bright@Data-IO.COM (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 21

In article <1990Mar1.140829.17199@druid.uucp> darcy@druid.UUCP (D'Arcy J.M. Cain) writes:
<In article <16055@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
<<The calloc() function is disrecommended.  Generally speaking, you should use
<<malloc() and initialize the contents yourself.
<I've heard that before but not the reason.  So why is it disrecommended?

The reasons are similar to the arguments about not using goto. calloc works
fine and is portable. Whether or not you use it is a religious issue.

Personally, I use it a lot. I usually set up my structs so the default,
benign values for members are 0. Using calloc to allocate them then
gets them initialized properly and efficiently. It also avoids bugs I've
had when I added a member to a struct, and forgot to initialize it in
some obscure location.

My code tends to use storage allocation heavilly, and the extra efficiency
gained by using calloc over a sequence of assignments is significant.

And no, I don't care about machines where 0.0 and NULL are not 0 bit
patterns. If someday I should be unfortunate enough to run across one,
I'll worry about it then!