> In general, it's bad to use stack if the only reason you are using > it is to seperate context, which is the point I was trying to make. > > OpenSSL takes this one level worse, and uses stack to avoid the > allocation and deallocation of context structures that are copies > of context structures translated to parameters, and back (one could > make a similar criticism of the FreeBSD VFS descriptor mechanism, > but at least there was a valid design reason for that one 8-)). > > I guess I could offer the alternative argument that buffers that > are allocated on the stack are subject to overflow in order to > get malicious code to execute... and that avoiding such allocations > makes such attacks much harder. > > The stack is really a necessary evil to handle the call graph; > abusing it for other reasons makes my teeth itch. 8-).
Do a Google search on "Cheney on the M.T.A.". It is a technique by Henry Baker for using a stack as a heap. The idea is to keep allocating on the stack until the OS says you can't any more and *then* do a copying garbage collection. Live objects are then copied off of the stack into a proper heap. The stack is now free so we reset the stack pointer to the bottom of the stack. The stack can be reused. Again and again. I am aware of at least one Scheme compiler that uses this technique. The point of this reference is that large objects on the stack are not necessarily bad. The real answer, as usual, is "it depends". I'd avoid using threads before I'd avoid using large objects on the stack (I am only talking about userland programs). Said another way, getting thread programming right is far harder than ensuring stack usage (or dealing with stack overflow). Just because some fool some where will misuse/abuse a technique is not reason enough to proscribe it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
