From: shenkin@still3.chem.columbia.edu (Peter Shenkin)
Subject: Re: Bug in SGI's malloc?
Organization: Dept. of Chem, Columbia U, New York
Date: Fri, 9 Oct 1992 20:15:21 GMT
X-Posted-From: still3.chem.columbia.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

In article <3030@contex.contex.com> james@sam.contex.com (James McQueston) writes:
>In article <qrc7vb8@sgi.sgi.com> jeremy@classic.asd.sgi.com (Jeremy Higdon) writes:
>>In article <1992Oct8.173404.24957@sol.ctr.columbia.edu>, shenkin@avogadro.barnard.columbia.edu (Peter S. Shenkin) writes:
>>> ... 
>>> No, it "should" return a NULL pointer when physical+swap has been exceeded.
>>> ... 
>>> malloc() behave "normally."  SGI considers the actual behavior to be
>>> a feature, not a bug.
>>
>>As do the people who requested it.  My understanding is that there are
>>some folks out there who have huge processes that want to do a quick fork
>>and exec...  Other folks had huge sparse
>>matrices that took a lot of virtual memory, but actually used very
>>little physical memory.
>>
>>If you want to have all virtual memory backed by phycical memory + swap,
>>then you can set availsmem_accounting in /usr/sysgen/master.d/kernel
>>and rebuild your kernel.
>>
>>jeremy
>
>IMHO the problem is that this "feature" is shipped on by default.  I
>see this conficting with the ANSI-C standard:
....
>I think this mis-feature should be turned off by default, else SGI cannot
>make the claim that their library is ANSI-C compliant.
>
>Beyond that, why must SGI ship systems with non-standard behavior as
>the default?  ....

As long as we're beating this horse, I'm going to get my own whip going
yet again, in the probably vain hope that the horse is not yet dead.

It is unprofessional to ship software that crashes;  we are taught in
school (or at least in K&R) to always check the value that malloc() returns
in order to avoid such crashes.  SGI's default behavior guarantees that 
a program written in a standard way will crash, given large enough input.
The whole purpose of malloc()'s having a return value in the first place
is to avoid this.  SGI's scheme removes this safeguard.  It also can result
in a program's chewing up huge amounts of CPU time before crashing, when
a NULL return from an early malloc() call would have terminated the
process early.

A software provider simply cannot tell his customers, many of whom are UNIX-
naive, and many of whom are individuals in a shared facility, to reconfigure
their kernels;  for one thing, it makes it sound as if the fault is the
application's, when it is not.

Whoever wants the non-standard behavior should be able to get it, but
the function that invokes it should not be called malloc().  At the
very least, there ought to be a compile-time flag that must be set
if the non-standard behavior is desired.  

Besides, how do all the users that want this behavior manage on other 
systems?  If this is really a needed facility for some applications, 
there must be some way to supply it to those applications while supplying 
normal behavior to everyone else.  I'm sure the people who need it do 
not limit their applications to SGI;  as far as I know, no one else 
even supplies such a facility, at least by default.  (But I'm willing 
to be corrected on this last assumption, if need be.)

	-P.
-- 
************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb*************************
Peter S. Shenkin, Department of Chemistry, Columbia Univ.,  New York, NY 10027
(212)854-5143      shenkin@still3.chem.columbia.edu      shenkin@cunixf.BITNET
*********************** UNIX:  the wave of the present ***********************