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: Dave Dodge
Subject: Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?
Date: Tue, 8 May 2007 05:04:05 -0400
User-agent: Mutt/1.5.12-2006-07-14

On Mon, May 07, 2007 at 05:33:51PM -0400, Rob Landley wrote:
> On Monday 07 May 2007 12:31 pm, David A. Wheeler wrote:

> I always mentally translated alloca() to something like (typecast)(char 
> anonymous[size]).  Does c99 allow you to do something like that in 
> expressions?  (I know it allows it in for loops...)

Probably the closest thing in C99 would be compound literals.  These
can create modifiable anonymous objects, including arrays, on the fly:

  foo((int[]){1,2,3});

But one of the constraints is that the type cannot be a variable
length array.

> > Interestingly, once alloca() is implemented, we can implement extensions 
> > like non-constant-length automatic arrays.  E.G., we could implement:
> > double f(int n) {
> >     double x[n];
> >     ....
> > }
> > by having the compiler detect that "n" is not constant and in such cases 
> > generate code equivalent to:
> >  double * const x = alloca(sizeof(double)*n);
> 
> I'm still a touch unclear on what's wrong with going the other way instead, 
> and emulating alloca() with an anonymous local char array...

Variable length arrays are only guaranteed to persist until the end of
the scope of the declaration.  alloca() memory is apparently assumed
to persist until the function returns, regardless of the scope of its
creation.

You could of course implement variable-length arrays to persist until
the end of the function -- I don't think there's anything in the
standard that forbids it.  But then you end up with an implementation
that probably can't handle things like:

  for (i = 0;i < 100000;i++) {
    char a[whatever];
    foo(a);
  }

                                                  -Dave Dodge




reply via email to

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