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