Safe coding practices

Martin Weitzel martin at mwtech.UUCP
Thu Jan 31 04:26:10 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.  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 at mwtech.UUCP, voice: 49-(0)6151-6 56 83



More information about the Comp.bugs.4bsd.ucb-fixes mailing list