Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!wuarchive!rex!ames!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.sys.sgi
Subject: Re: realloc reactions ??
Summary: flowers are not solar
Message-ID: <85973@sgi.sgi.com>
Date: 18 Feb 91 19:50:55 GMT
References: <9102150952.AA24219@karron.med.nyu.edu> <4786@network.ucsd.edu> <1991Feb15.213747.3170@cunixf.cc.columbia.edu>
Sender: guest@sgi.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 21


>                     Why does SGI's realloc() barf on
> a null pointer....


There is a brand of solar workstation with a free() that does not care what
it's arg is.  You can free() automatic variables, because their version
first tries to validate the pointer, and ignores what looks wrong.  The
code written by that engineering organization is--let's be polite--care free
about malloc/free/realloc args.

Some of us consider that practice less than fastidious, and while not
strictly wrong, similar to using int's as pointers.  For years we have been
painfully aware of such solar code, including kernel code.

Being careful to always pass good things to free & relloc makes correct
code bigger, but also makes incorrect code fail sooner.  The hard malloc
bugs are the ones whose corruption causes disaster 10e10 cycles later.


Vernon  Schryver,  vjs@sgi.com