This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [RFA] alloca coding standard


On Tue, Nov 14, 2000 at 10:42:28AM -0500, Jim Blandy wrote:
> 
> Nick Duffek <nsd@redhat.com> writes:
> 
> > 
> > On 13-Nov-2000, Kevin Buettner wrote:
> > 
> > >I think we ought to just pick a number (in bytes) and not mention
> > >pages at all.  
> > 
> > I agree.  I'll rework the patch to specify 512 bytes or whatever number
> > the group thinks is reasonable.
> 
> 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), 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 (for any possible machine, including those
not yet written for machine independent code).  Thus I would say in MI code,
you should not use alloca based on the number of registers, but it is perfectly
fine to use it in MD code....

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]