Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!seismo!hao!hplabs!sri-unix!dan@bbncd From: dan%bbncd@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: Re: stack memory allocation Message-ID: <2790@sri-arpa.UUCP> Date: Tue, 5-Jul-83 15:31:00 EDT Article-I.D.: sri-arpa.2790 Posted: Tue Jul 5 15:31:00 1983 Date-Received: Sat, 9-Jul-83 20:19:48 EDT Lines: 24 From: Dan FranklinThe VAX 4.1BSD C compiler, like many C compilers, pushes arguments on the stack as they are generated for a function call. Thus, salloc() will not work in: foo(arg1, salloc(N), arg3); Arg3 gets pushed on the stack, then salloc() is called and its return value is pushed, then arg1, and finally foo() is called. But arg3 is far away from the other arguments; foo() will never find it! I couldn't make the VAX compiler use the stack for expression analysis; I probably didn't make it complicated enough. This is a common strategy, though, and if you think you might run the code on another system someday you should avoid it. Simple assignment statements would probably work: p = salloc(N); on machines like the VAX and PDP-11. On at least one architecture I know of, though, the compiler generates ALL references to local vars off sp; thus salloc() would fail rather spectacularly no matter how you used it. Also, the optimizer is no respecter of statement boundaries, so maybe even doing an salloc() NEAR some function calls or complex expressions could screw up. Personally, I think salloc() is too implementation-dependent to be worth it, even though it would be incredibly useful. Dan Franklin