Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!uunet!samsung!uakari.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!thyme!kaleb
From: kaleb@thyme.jpl.nasa.gov (Kaleb Keithley)
Newsgroups: comp.lang.c
Subject: Re: realloc() (was: Re: Safe coding practices)
Message-ID: <1991Jan30.204210.5593@thyme.jpl.nasa.gov>
Date: 30 Jan 91 20:42:10 GMT
References: <23975:Jan2516:36:5891@kramden.acf.nyu.edu> <1991Jan30.121425.16882@unhd.unh.edu> <1991Jan30.193308.3897@athena.mit.edu>
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 24

In article <1991Jan30.193308.3897@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
>In article <1991Jan30.121425.16882@unhd.unh.edu>, pas@unhd.unh.edu (Paul A. Sand) writes:
>|> Emphasis is Jaeschke's. Even a tyro like me can recognize that you
>|> are in big trouble if (a) the realloc() fails, (b) ptr is your only
>|> access to the block, and (c) you had something important there.
>
>  I believe that if the realloc() fails, the memory block pointed to by the
>pointer passed into realloc() is no longer guaranteed to be valid.  Therefore,
>Jaeschke is right -- after realloc() returns NULL, you should not try to use
>the block whose address you passed into realloc().

the man page (on Sun) states the following:     
     ... If unable to honor a reallocation request, realloc() leaves 
     its first argument unaltered....

K&RII states the following:
    ... realloc returns [...] NULL if the request cannot be satisfied, in which
    case [the first argument] is unchanged.

-- 
Kaleb Keithley                        kaleb@thyme.jpl.nasa.gov

As of right now, I'm in charge here now...                  Alexander Haig.
Voodoo Economics, that's what it is, voodoo economics.      George Bush