[BusyBox] modified libbb/arith.c -- size reduction (30%) and bug fix

Aaron Lehmann aaronl at vitelus.com
Sat Aug 25 23:54:14 MDT 2001


On Fri, Aug 24, 2001 at 10:00:47AM -0600, Manuel Novoa III wrote:
> Hello all,
> 
> Here's a modified libbb/arith.c (the diff was larger than the file)
> that fixes several bugs (described in the comments) and reduces the
> generated code size for i386 by about 400 bytes (30%).  I haven't
> had much time to code of late and am using an old 486 laptop while
> I'm away, so I'm posting this in hopes that others will test it
> more thoroughly.

Hi,

That's great! You can do critical performance analyses ;-).

I got a chance to look at your new version in detail. First off, you
added 2 to datasizes. Don't do that. First of all, you only need that
extra space on 'stack' (not numstack) and only the left paren gets
pushed. So, I would just change

	operator *stack = alloca(datasizes * sizeof(operator))
to
    operator *stack = alloca(datasizes * sizeof(operator) + 1)

and leave datasizes untouched.

Then, you make the parser a lot more error-aware. I'm not sure whether
I want this. IMHO it makes sense to report an error when an expression
is nonsensiscal, like 2//7 or something. But as for parens, maybe we
should be less strict to preserve size. If we allow close parens to be
unmatched and pretend that there's an open paren at the beginning of
the expression (it's simple, just remove "if (op == TOK_RPAREN) goto
err;"), then we can skip prepending a '(' to the expression. It means
that expressions like '1+2)/3)%4' etc become valid. IMHO it's a handy
feature, and it actually reduces code size. I don't know what POSIX
says about whether illegal syntax can be intepreted shell-dependantly.






More information about the busybox mailing list