of course!

[Peter da Silva]

In article <1989Nov22.224209.28911 at athena.mit.edu> jik at 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 at ficc.uu.net> <peter at sugar.lonestar.org>.
 'U`  --------------  +1 713 274 5180.
"The basic notion underlying USENET is the flame."
	-- Chuq Von Rospach, chuq at Apple.COM