Re: [RFA] alloca coding standard

[Jim Blandy <jimb at zwingli dot cygnus dot com>]

> > Often the size will be data-dependent, and not under the control of
> > the person submitting the patch at all.  Is a register file 512 bytes
> > long?
> > 
> > It must be a judgement call, so I don't see much point in being
> > precise.  Rather, the documentation should explain the issues, so the
> > person can make an educated decision.
> 
> Ummm, it is those data dependencies that are the root of the problem.  Didn't
> we just have somebody post that in bfd-land, they had an alloca based on the
> number of sections?  In a.out type formats, you get 3 sections, in normal ELF
> you might get 10 or so, until the user does -ffunction-sections and/or
> -fvariable-sections, and suddenly now, the alloca is for thousands of elements,
> if not millions.
> 
> So, IMHO (or IMAO if you prefer)

You're so A, Michael. :)

> alloca should not be used on with any value that is data dependent,
> unless it can be shown that the value will never be bigger than your
> max size for alloca

It seems to me that if you can establish a maximum size, you might as
well simply declare the array to be that large to begin with, and
forget about alloca altogether.  Your constraint sounds like "You may
only use alloca when it's not needed."  :)