Xref: utzoo comp.bugs.4bsd:1673 comp.std.c:4191 comp.lang.c:35510
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!rpi!uupsi!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.bugs.4bsd,comp.std.c,comp.lang.c
Subject: Re: Safe coding practices
Message-ID: <14970@smoke.brl.mil>
Date: 25 Jan 91 16:53:57 GMT
References: <1991Jan24.060707.22566@tkou02.enet.dec.com> <22870@well.sf.ca.us> <22311:Jan2502:34:1191@kramden.acf.nyu.edu>
Followup-To: comp.bugs.4bsd
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 9

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.  Of course it may return
NULL even if you're attempting to shrink the allocation, although it is
unlikely that an implementation would be so deficient.

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