Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!fub!opal!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.bugs.4bsd
Subject: Re: Safe coding practices
Message-ID: <1074@mwtech.UUCP>
Date: 30 Jan 91 17:26:10 GMT
References: <1991Jan24.060707.22566@tkou02.enet.dec.com> <22870@well.sf.ca.us> <22311:Jan2502:34:1191@kramden.acf.nyu.edu> <14970@smoke.brl
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 26

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.  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. There are a number of reasons
why this "unlikely" behaviour could happen, though the typical UNIX system
with hardware MMU's won't be likely to expose it. But on less sophisticated
hardware and operating system environments it may be advantageous to
copy the shrunk data block to somewhere else, do some reorganization
of the heap and copy it back ... but and in the meantime the space which
was available at the start got consumed by some other request.

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

RIGHT! Don't assume anything that *can* fail will *not* fail in your
particular case. (And don't apply "logic" - there may be reasons you can't
see right now because they are outside the range of your experiences.)
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83