Comments on svn 16057.

[Rob Landley]

On Saturday 09 September 2006 1:00 pm, Denis Vlasenko wrote:
> On Wednesday 06 September 2006 19:51, Rob Landley wrote:
> > http://busybox.net/downloads/patches/svn-16057.patch
> > 
> > RESERVE_CONFIG_BUFFER() is actually a bit of a dinosaur.  It turns out 
that 
> > most of the times I've tested, declaring a pointer and using xmalloc() (or 
> > xzalloc()) actually results in smaller code.  (On x86 anyway.)  And the 
only 
> > reason for declaring stuff on the stack was that it was theoretically 
> > smaller...
> > 
> > And in this particular case, xzalloc() saves the calls to memset().
> > 
> > I'm considering removing RESERVE_CONFIG_BUFFER() and just using malloc() 
when 
> > it makes sense and declaring stuff on the stack when it makes sense.  
Anybody 
> > have any opinions on this?  If nothing else it simplifies the code...
> 
> Very much agree.
> 
> What are the rules about variable-length array on stack (gcc extension)?
> Are they allowed? IIRC you can even do
> 
> char message[strlen_and_other_scary_math];

I don't have a major objection to them (we use other gcc extensions like 
replacing "thing ? thing : otherthing" with "thing ? : otherthing", and 
there's even a patch to add support for this one to tcc.

That said, I usually think of this kind of thing in terms of alloca().  That's 
not posix or susv3 either, but I honestly don't care.

Rob
-- 
Never bet against the cheap plastic solution.