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

[Tom Cameron]

Aaron,
	I, for one, do _not_ like the idea of programing around user errors.
After working in the computer industry for 12 years, the one thing that
I have found is that you should (in a polite way) make people aware of
their errors. Even if it makes the final product smaller, I don't like
the idea of the shell not telling me that I have made a mistake.
Additionally, I don't like the idea of the shell deciding what I was
attempting.  In the example you used "'1+2)/3)%4'", the shell would
assume that 1) there wasn't supposed to be anything before the "1",
which may be completely incorrect in a case where a variable is
pre-pended to the string that the shell is interpreting, and 2) I, the
author of this string, have placed the correct paren. in the correct
place...which we all know how easily a typingg<BS> mistake can be made.
	Anyway, I certainly don't want to come off as a pompos wind-bag
(although I'm sure that it is popular thought by now), but programming
to cope with user foolishness is what got Microsoft to be able to
release Windows ME.  ;-)  Get it?  They wrote it as one big work-around
for the flaw of all times (purchasing Win ME)?  It's kinda like "To
understand recursion, one must understand recursion", or "GNU = Gnu is
Not Unix"?  Anyway, that's just my take...please correct me if I'm
wrong.

-Tom

Aaron Lehmann wrote:
> 
> 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.
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/mailman/listinfo/busybox