realloc() (was: Re: Safe coding practices)

Paul A. Sand pas at unhd.unh.edu
Wed Jan 30 23:14:25 AEST 1991


In article <23975:Jan2516:36:5891 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>Some versions of realloc() return the original pointer rather than 0 if
>they run out of memory. So you have to code the malloc()/bcopy()/free()
>sequence yourself if you want error checking.

Other posters have pointed out that such realloc()'s are seriously
broken, but I wonder how many versions "some versions" actually are.  A
brief check of my portability references (Jaeschke's _Portability and
the C Language_, Rabinowitz's and Schaap's _Portable C_, 1st and 3rd
editions of Harbison & Steele) doesn't turn up any warnings about such
behavior. (And these folks seem to warn about *very* unlikely things.)

But as long as I'm reading, I did notice a howler in Jaeschke's text,
on page 320:

	You should ALWAYS use realloc as follows:

	ptr = realloc(ptr, new_size);

Emphasis is Jaeschke's. Even a tyro like me can recognize that you
are in big trouble if (a) the realloc() fails, (b) ptr is your only
access to the block, and (c) you had something important there.
-- 
-- Paul A. Sand                |
-- University of New Hampshire | I ain't here on business, baby.
-- uunet!unhd!pas              | I'm only here for fun.
-- pas at unhd.unh.edu            |



More information about the Comp.bugs.4bsd.ucb-fixes mailing list