tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem


From: David A. Wheeler
Subject: Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?
Date: Mon, 07 May 2007 21:45:56 -0400 (EDT)

Daniel Glöckner:
> 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 
expected.

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.

Rob Landley:
>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.
>Okay...

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 
original proposal.

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 
thing.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]