Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.unix.wizards
Subject: Re: of course!
Message-ID: <7132@ficc.uu.net>
Date: 28 Nov 89 19:50:42 GMT
References: <152@norsat.UUCP> <2586@unisoft.UUCP> <15769@bloom-beacon.MIT.EDU> <17264@rpp386.cactus.org> <4526@ski.cs.vu.nl> <17303@rpp386.cactus.org> <1051@root44.co.uk> <1989Nov22.224209.28911@athena.mit.edu>
Reply-To: peter@ficc.uu.net (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 53

In article <1989Nov22.224209.28911@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
> Furthermore, a malloc is far more likely (in my experience) to cause a
> program to run out of memory than a procedure call is.

I take it you have never worked on a machine with a fixed-size stack.

And if your stack size is variable, then your big allocation can still
increase your stack segment, and it's still never going to decrease. So you
still lose there.

If you're *real* worried about this, the best solution is a stack-like
memory allocator. Here's a totally bare-bones one that falls back on
malloc. It's *NOT* a malloca replacement, if anyone's thinking of that.

------allot.c:
#include "allot.h"
char *here = lotsaram;

------allot.h:
char lotsaram[BIG];
char *here;

#define ALLOT(n) ( (here+(n) > &lotsaram[BIG]) ? malloc(n) : (here += (n)) )
#define FORGET(p) ( ((p) >= lotsaram && (p) <= &lotsaram[BIG]) ? (here = (p)) : free(p) )

------isadir.c:
#include "allot.h"

isadir(string)
char *string;
{
	int len;
	char *copy;
	int res;
	
	len = strlen(string)
	copy = ALLOT(len+2);

	if(!copy) return -1;

	strcpy(copy, string);
	strcpy(&copy[len], "/.");

	res = access(copy, 0);

	FORGET(copy);
	return res != -1;
}
-- 
`-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>.
 'U`  --------------  +1 713 274 5180.
"The basic notion underlying USENET is the flame."
	-- Chuq Von Rospach, chuq@Apple.COM