Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!wuarchive!uunet!pilchuck!dataio!fnx!nazgul!bright
From: bright@nazgul.UUCP (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: realloc() (was: Re: Safe coding practices)
Message-ID: <263@nazgul.UUCP>
Date: 10 Feb 91 18:06:56 GMT
References: <1991Jan30.193308.3897@athena.mit.edu> <23975:Jan2516:36:5891@kramden.acf.nyu.edu> <1991Jan30.121425.16882@unhd.unh.edu> <1991Jan30.201955.21797@ux1.cso.uiuc.edu> <1991Jan30.204159.5726@athena.mit.edu>
Reply-To: bright@nazgul.UUCP (Walter Bright)
Organization: Zortech, Seattle
Lines: 19

In article <1991Jan30.204159.5726@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
/If you want to assume that
/because ANSI C specifies realloc() as you quoted, all implementation of
/realloc() you come across specify it in that way, that's your right, but I
/doubt such an assumption is portable

What I do is assume realloc works in an ANSI way across all platforms. If
I discover one in which realloc is broken, the workaround consists of
writing my own replacement in terms of malloc, memcpy, free.
You don't have to suffer the lowest common denominator in library functions.
I also have a set of str... and mem... functions which are written portably,
and are used when I'm stuck on a system that doesn't support them.

Some functions can't be fixed simply, like fork, but a lot can be done if
you are willing to do a minor amount of work.

P.S. I'm not talking about patching the system's libraries or headers, I
insert the replacements in a separate module and link them in, thus overriding
the system libraries.