[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem
David A. Wheeler
Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?
Mon, 07 May 2007 21:45:56 -0400 (EDT)
> Ok, and here is my understanding of what would happen:
Wow, you're right; I was misled by what happens on some other compilers (vs.
what tinycc _actually_ does). Thanks for setting me straight!
> The result is not immediately placed on the real stack.
> It stays in a register and is moved to an anonymous variable when the
> register is needed. This happens for all parameters.
Ah! I see. It appears that I can _count_ on there being exactly 1 parameter
on the stack when calling a 1-parameter function like alloca(), and NOTHING
more, even when an expression is only partly evaluated. And the function
prologue seems to reserve space for ALL blocks (including variables in
subblocks). For implementing alloca() traditionally (on the stack), I couldn't
ask for a better situation.
So maybe it's not so hard to implement alloca() traditionally, then... I just
misunderstood how tcc was doing what it did. Thanks!! If I can get alloca() to
truly allocate straight off the stack, that'd be fantastic & more than I
I'll need to investigate how it interacts with the buffer-overflow detection
stuff, for those who choose to use it. If you have any thoughts on that, love
to hear it.
>I thought the original reason malloc() and alloca() differed was one allocated
>on the heap, and one on the stack. You're proposing emulating allocating on
>the stack with allocating on the heap, in the name of correctness.
Right; a _nice_ aspect of emulating stack allocation with heap allocation is
that it's practically all done with libraries, making it easier to do (and more
confidence in it being correct). For example, using the pre-existing malloc()
meant that I didn't have to examine how to interace with the bounds stuff. But
_maybe_ alloca() can be done the more traditional way (on the stack), so I'll
see if it can be. If I find a last-minute surprise, I can still back off to my
Which means that variable-length arrays can still be implemented using
alloca()... but they'll be stored on the STACK, not the heap, so that's a great
This is exactly why I posted my thoughts before coding, because while I'm
learning how the code works I can easily make basic errors in understanding. I
really appreciate the feedback, thanks.
--- David A. Wheeler
Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?, Rob Landley, 2007/05/07