On Thu, Mar 20, 2003 at 04:52:15PM -0800, Tim Riley wrote: > > > "Micah J. Cowan" wrote: > > > On Thu, Mar 20, 2003 at 10:15:43AM -0800, Tim Riley wrote: > > > > > > > > > > The first library had malloc(). Always > > > > using calloc() would be a ridiculously inefficient way to obtain > > > > memory if you're going to just set it again anyway. > > > > > > It might seem inefficient to set memory twice, but you're looking > > > at it from the CPU's point of view. Instead, by looking at it from > > > the programmer's point of view, the extra nanoseconds it takes > > > to always get a clean data structure is worth hours of time savings > > > by not having to trace a core dump. > > > > You're saying that you'd rather have your program silently set the > > wrong memory location than to vomit? In my experience, the earlier in > > the development stage you catch a bug, the better. > > > > What situation are you thinking of where an accidentally unset, > > malloc()ed structure would cause a core dump upon access that would > > not be duplicated had calloc() been used? > > The vulnerability with malloc() occurs when working with pointers. > It's common to test if a pointer has been set > by placing it inside an "if" statement before referencing it. > If you always use calloc(), all of your pointers will be > initialized with zero.
All bits zero != NULL. This is a common misbelief, which happens to be true on a number of platforms. But it is not guaranteed to be true, and is not on several platforms, though I conced that they are not the mainstream. See: Sec. 5 of the C FAQ: ~http://www.eskimo.com/~scs/C-faq/s5.html Any number of comp.lang.c posts: http://groups.google.com/groups?as_q=NULL%20calloc%28%29&as_ugroup=comp.lang.c Especially this one by the author of the FreeBSD C Library (last paragraph): http://groups.google.com/groups?q=NULL+calloc()+group:comp.lang.c+author:Chris+author:Torek&selm=18764%40dog.ee.lbl.gov > For the following example > it's clear that a core dump might occur; however, if the program were > 1000 lines long and the variables set in different locations, tracing > could be a bear. > > typedef struct > { > char *name; > char *address; > char *city; > char *state; > char *zip_code; > } PERSON; > > int main( int argc, char **argv ) > { > PERSON *person = malloc( sizeof( PERSON ) ); > > person->name = "fred"; A core dump could occur right here, with or without calloc(), considering you didn't check malloc()'s return. > if ( person->name && person->zip_code ) > { > printf( "For person = %s, got zip code = %s\n", > person->name, person->zip_code ); > } > } > > If calloc() had been used, no one would have noticed the delay and no > core would be dumped. Provided that one is using a system on which NULL happens to be all-bits-zero. Which we all are on this list, but can we guarantee that the code you write won't be ported to such a system? And I submit that without the core dump, the bug of having forgotten to set *person's fields just got much, much harder to track down. -Micah _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
