Re: Changing storage allocation for C

["Ranjit Singh" <ranjit at sukhisoft dot com>]

    But the amount of work seems to be really nontrivial.

I can appreciate that from what you have written..

    The stack is normally also used for

    (a) temporary storage while evaluating complicated expressions (but that
can
    also be done by introducing explicit compiler temporary variables)

    (b) passing arguments to subroutines (those would then have to be
"pushed"
    relative to %ebp, instead of %esp)
You seem to have a solution for those two.

    (c) in alloca() to get some region of memory with a size calculated at
run time
At first glance, your  solution to b) would do, so long as all code is
recompiled. I'm sure there is an issue here I am unaware of..

    and then there is setjmp()/longjmp(), there is stack unwinding in e.g.
C++
    expressions, and there is the debugger that has to be told about this...
All
    in all it sounds as if it was a bit more work than you suggest.
Yes, you got that right! Do setjmp/longjmp use the stack to pass the value
returned, or what exactly?
    Apart from being incompatible with existing libraries.
Well, if it were sufficiently useful, I for one have no problem recompiling,
iff it is true that the code would function identically (since using a
stack) but without leaving the main stack open to corruption.

    I think that the amount of work is the main reason why it hasn't been
done.
    Apart from stack smashing attacks, there is also the issue of "normal"
stack
    smashing bugs that you want to track down in a debugger, and those tend
to be
    hard.  Without a valid stack, I have seen debuggers crash, and then it's
back
    to printf() debugging.  (Electric fence doesn't help with stack
problems.)  A
    recipe like yours would cure most cases, and I'd be all for it, although
for
    reasons different from yours.
My feeling is that if the regular stack is only used for saving registers,
and /never/ for user data, you would find less problems with stack
unwinding. The point is that whether it's malicious data or poor coding,
stack data is protected.

Thanks for the response,
Ranjit.