Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!agate!ucbvax!ucsd!sdcc6!sdcc13!cpenrose
From: cpenrose@sdcc13.ucsd.edu (Christopher Penrose)
Newsgroups: comp.sys.next
Subject: Re: NeXT alloca() Hoaxarama
Summary: talking to myself
Keywords: malloc(), alloca(), hoax, bugs
Message-ID: <16213@sdcc6.ucsd.edu>
Date: 31 Jan 91 19:35:46 GMT
References: <15929@sdcc6.ucsd.edu>
Sender: news@sdcc6.ucsd.edu
Distribution: na
Organization: University of California, San Diego
Lines: 24
Nntp-Posting-Host: sdcc13.ucsd.edu

In article <15929@sdcc6.ucsd.edu> cpenrose@ucsd.edu (Christopher Penrose) writes:
>--text follows this line--
>Ok.  I spoke too soon.  I have discovered what appears to be a
>alloca() bug within NeXT 2.0 gcc 1.36.

Before I am corrected by the net, I posted this article over a week ago.
It just surfaced.  Anyway, first of all, alloca() has nothing to do
with the problems that I was having.  NeXT has added some zone features
to malloc(), and a few bugs may have crept out.  Two NeXT representatives
were very helpful as well as Scott Hess.  Thanks people!  There was one
monothink unit that kept telling me that nothing was wrong with malloc()
and that obviously my code was messed up.  I offered him the code and also
told him that the same code worked fine on my 68030 NeXT 1.0a machine,
a sparcstation, a sun 4/330, a Vax 11/780, a dec 5400 et al.  Sorry for
complaining.  I solved my problem by using a minimum malloc() size 
threshold.  My experiences with malloc_debug() indicated that my pointers
were infact getting munched beneath my program code.  Anyway, I am sure
that NeXT is working hard on improving their new malloc() features.

One more thing:  NeXT deserves applause.  I read in the release notes
that objective-c now supports runtime loading of objects.  Good work!

Christopher Penrose
jesus!penrose