Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!gatech!udel!haven!adm!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.bugs.4bsd
Subject: Re: Safe coding practices
Message-ID: <26081:Jan2520:59:5691@kramden.acf.nyu.edu>
Date: 25 Jan 91 20:59:56 GMT
References: <22870@well.sf.ca.us> <22311:Jan2502:34:1191@kramden.acf.nyu.edu> <14970@smoke.brl.mil>
Organization: IR
Lines: 22

In article <14970@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
> In article <22311:Jan2502:34:1191@kramden.acf.nyu.edu> brnstnd@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