[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [BusyBox] modified libbb/arith.c -- size reduction (30%) and bug fix
From:       mjn3 () busybox ! net (Manuel Novoa III)
Date:       2001-08-26 18:54:33
[Download RAW message or body]

Aaron,

On Sat, Aug 25, 2001 at 09:54:12PM -0700, Aaron Lehmann wrote:
> 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

It was a conservative quick fix as I was hacking on the code.  I forgot
to go back and fix it correctly.  Thanks.  Hopefully I post a version
with this, vodz's fix, and your comments tomorrow.

> 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.

I _really_ think that expressions with mismatched parens _are_ nonsensical.
And even if the standards allow us to "do what we think the programmer meant"
I think that allowing mismatched parens is a bad idea from the standpoint
of script portability.

Manuel



[prev in list] [next in list] [prev in thread] [next in thread]