Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!uw-june!uw-entropy!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: malloc+copy+free vs realloc (was Efficient coding)
Message-ID: <1734@dataio.Data-IO.COM>
Date: 31 Oct 88 19:42:24 GMT
Article-I.D.: dataio.1734
References: <3105@hubcap.UUCP> <34112@XAIT.XEROX.COM> <1700@dataio.Data-IO.COM> <1730@dataio.Data-IO.COM> <14232@mimsy.UUCP>
Reply-To: bright@dataio.Data-IO.COM (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 22

In article <14232@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>There is, however, one case where I do use
>malloc+copy+free instead of realloc:  If the data are important and
>must not be destroyed by a failed realloc.  The draft standard says
>that this is already so; but I have my doubts about current implementations.

In which case, as I said, you write your own realloc(), as in:

#if BADREALLOC
extern void *mem_realloc();
#else
#define mem_realloc(p,oldsize,newsize)	realloc((p),(newsize))
#endif

and write my_realloc to do the malloc/copy/free. This gives you the advantage
of using a well-implemented realloc with a fallback to your own if the system
one is bad.

I have used a (slightly more complex) variation on this for all my software
for years, and have been pleased with the results. I try to code in ANSI
as much as possible, and use the macro preprocessor for compatibility with
stone age compilers. I also port the ANSI library routines when I need them
for some port, instead of trying to do without them.