Path: utzoo!utgpu!attcan!uunet!mcvax!cernvax!hjm From: hjm@cernvax.UUCP (hjm) Newsgroups: comp.lang.c Subject: Re: alloca Message-ID: <787@cernvax.UUCP> Date: 4 Aug 88 10:06:21 GMT References: <3950010@eecs.nwu.edu> <62170@sun.uucp> <62363@sun.uucp> <8293@smoke.ARPA> <19895@cornell.UUCP> <6498@aw.sei.cmu.edu> Reply-To: hjm@cernvax.UUCP () Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Lines: 39 Two points about alloca: - not knowing the size of the stack frames is a big pain on a non-virtual memory machine. If a program is non-recursive, then it possible to calculate at compile time the maximum stack usage and allocate just that space for the stack in a multi-tasking system, minimising memory usage and avoiding the need for stack relocation or extension. - why have two mechanisms for memory allocation when one will do? malloc() is perfectly adequate in that it gives you the memory you require when you require it (if it's available) and free() lets you give it back when you want to. Simple to implement portably, and easy to understand. If you find it difficult to remember to give back memory at the end of a function then why not have a function which does the following: alloc_and_call (func, size) void (*func)(); int size; { char *p; p = malloc(size); func(p); free(p); } OK, so that's not perfect. Parameter passing is a problem, but just a small part to add on. Portable code for those people who can't remember to deallocate stuff they asked for. When physical memory gets tight, how do you propose that malloc and alloca should talk to each other so that they don't tread on each other's toes? As a general principle, I would advocate one method for doing something rather than two if there is any choice at all. Uniformity is something that aids thinking and allows people to solve the real problems of writing the code to do the job, and not to waste time wondering "should I use malloc or alloca". Hubert Matthews