Re: [Tinycc-devel] Buiding binutils 2.17 (needs dynamic arrays).

[Antti-Juhani Kaijanaho]

On Wed, Oct 03, 2007 at 11:10:52PM -0500, Rob Landley wrote:
> > > > int foo(size_t n, int arr[n++])
> > > > {
> > > >         ...
> > > > }
> > >
> > > In the absence of code I care about actually doing this, I'm not even
> > > going to try to support that.  Just use int *arr and copy the darn thing
> > > with alloca() if you need to.  This is getting _way_ too fancy at the
> > > language level...
> >
> > alloca is not portable, VLAs (theoretically) are.
> 
[...]>
> "not portable" is a strange argument to make when talking about how tcc 
> chooses to call other bits of tcc, internally...

But I wasn't talking about tcc internals here.  You said, "Just use int
*arr and copy the darn thing with alloca() if you need to" and I took
that to mean that the *programmer* should "just use int *arr etc".
My comment was that a programmer may prefer VLAs to alloca for
(theoretical) portability reasons.

Of course, if you implement the local VLA variables part of this, which
I think you are talking about implementing, the user can just make a
local VLA and copy to that and not use alloca :)

> > That *is* what gets passed.  The VLA degenerates to a pointer like any
> > other array parameter.
> 
> So why the heck are they allocating space for it in the function definition?  

It isn't allocating space for the array.  This isn't different from what
happens if you write

int foo(int foo[5])
{
 ...
}

> I don't think I've encountered a package that tries to use _Complex yet, and 
> I'd expect that to live in the C library anyway.  (The standard may say 
> otherwise, but so what?)

Since C doesn't have user-defined operator overloading, some compiler
support is necessary.  I expect it'll be implemented mostly by
generating calls to library functions :)

-- 
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/