[Toybox] [PATCH] expr

[Rob Landley]

On 06/05/2013 07:29:38 PM, Daniel Verkamp wrote:
> On Tue, Jun 4, 2013 at 11:06 PM, Rob Landley <rob at landley.net> wrote:
> >> - Decide what to do about integer overflow (the current code can
> >> execute undefined signed overflow behavior with large inputs; GNU
> >> coreutils expr detects this and prints an appropriate error).
> >
> >
> > What does Posix require?
> 
> The expr command description doesn't mention anything about integer
> overflow at all; I don't know if there is some overall POSIX
> requirement that applies.

Well, how did _you_ find out about it?

Absent the standard explicitly requiring something, the next thing I  
care about is real world users. Who will _not_ doing it inconvenience?

> [...]
> > I note that part of the reason I've held off with this one is that  
> (like
> > test.c) it's basically shell behavior. Test is [ ] and expr is $((  
> )), and
> > they should eventually share code. I haven't yet studied _how_  
> similar they
> > are and how much (if any) they diverge...
> 
> In expr's case, at least, there is not much that can be shared.  Each
> part of the expression in expr must be a separate argument and
> properly escaped in the shell, whereas the shell arithmetic expansion
> does not have these restrictions, e.g.
> 
>   expr 5 + 3 \* 10
> vs
>   echo $((5+3*10))
> 
> Invocations like `expr 5+3` or `expr "5 + 3"` don't work.

The UI isn't shared, but some of the plumbing behind the scenes might  
be. Once you've tokenized the input you have to work out order of  
operations and perform the

Last time I did this it had two stacks (one for operators and one for  
numbers), I should see if I can dig up my old code on this. It handled  
arbitrary (x^(7+2/4)/37) stuff, with variables even. Alas, it was  
written in java, and this was 1998, but still...

Or I could just read what you've done. :) (It's on my todo list!)

Rob