Safe coding practices

Dan Bernstein brnstnd at kramden.acf.nyu.edu
Sat Jan 26 07:59:56 AEST 1991


In article <14970 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes:
> In article <22311:Jan2502:34:1191 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
> >... there's no safe way to use realloc() ...
> In Standard C realloc() is required to be safe.

Yes, but we're talking about the real world, not (just) Standard C.

> The relevant point is that one should be prepared to deal with realloc()
> failure, not blindly assume it will always work.

The relevant point is that if you depend on realloc() either returning 0
or giving you a pointer to the right amount of memory, your program will
fail on quite a few machines if it runs out of space. If you want to use
reallocation in a portable program, do the malloc()/copy/free()
yourself.

This is like testing putc() for failure. Sure, the standard insists that
if putc() returns EOF then there's been an error. But a portable program
cannot depend on this behavior, because there are just too many machines
where putchar((char) 255) returns EOF.

---Dan



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