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

[Rob Landley]

On Wednesday 03 October 2007 10:30:12 pm Antti-Juhani Kaijanaho wrote:
> On Wed, Oct 03, 2007 at 05:17:23PM -0500, Rob Landley wrote:
> > If you jump inside its scope you must initialize it (call alloca).
>
> I'm a little worried about the "use alloca" thing you have here (in
> general, not just this particular quote).  alloca has all sorts of nasty
> problems, which is a reason why it's not in the standard and VLAs are.
> Of course, it's just a worry, I don't have a specific objection.
>
> Just allocate the array from the stack.  Decreasing ESP by the size and
> then using the resulting ESP as the array start pointer ought to work,
> as far as I can see.  Not having looked at the tcc code I'd assume
> that's what tcc does when allocating auto variables in any case.

I need to look into the local variable allocation code some more no matter 
what I do...

> > Soundsw like you can't jump over the initialization.
>
> Yes, I believe that's the intent.
>
> BTW, are you aware of the C99 rationale document?  It explains why
> some stuff is in the standard and why some other stuff is not, and why
> the stuff that is in there is the way it is.
>
> http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf

No, I'd never heard of it.  Opened now, but it's 200+ pages and not something 
I'm likely to finish reading today. :)

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

I meant that there is some alloca() code in tcc right now, and I might be able 
to turn the VLA allocation into a call to the alloca() that's there right 
now.  (Or there might be a better way to do it, but this is an area of the 
code I'm not familiar with.  There's no shortage of those.)

"not portable" is a strange argument to make when talking about how tcc 
chooses to call other bits of tcc, internally...

> But I agree, not 
> supporting everything is not a problem, as long as the compiler doesn't
> assign non-standard semantics for the stuff.
>
> > kraah+1 resolves to a pointer, that should be what gets passed on the
> > stack,
>
> 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?  
The contents of that pointer then get copied into the new local variable?

> > and if the function wants to copy if the function can copy it.
>
> Yes.
>
> > Darn silly to try to make the language do this.  This is C, not python...
>
> I believe the appropriate comparison in this case is "This is C, not
> Fortran".  VLAs (like _Complex) has a significant (potential) user base
> in the scientific computing community.

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?)

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.