Path: utzoo!utgpu!watserv1!watmath!att!emory!gatech!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.bugs.4bsd
Subject: Re: Safe coding practices
Message-ID: <15027@smoke.brl.mil>
Date: 31 Jan 91 17:45:48 GMT
References: <22311:Jan2502:34:1191@kramden.acf.nyu.edu> <14970@smoke.brl <1074@mwtech.UUCP>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 16

In article <1074@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes:
>In article <14970@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>>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.
>YES! An important point and I wouldn't even say that an implementation
>is necessarily "deficient" if this happens.

While I generally agree with your comments, the reason I would think
that such an implementation was unnecessarily deficient is that the
C standard requires that, in cases where realloc() reports failure,
the original data be left unchanged at the same, still validly
allocated, location.  (Not exact wording, but that's the meaning.)
Therefore realloc() COULD simply return the first argument pointer
in that case; nothing is actually gained by it returning NULL.