[Toybox] [PATCH] expr

[Daniel Verkamp]

On Tue, Jun 4, 2013 at 11:06 PM, Rob Landley <rob at landley.net> wrote:
> On 06/04/2013 03:09:52 AM, Daniel Verkamp wrote:
[...]
>> The expression is evaluated using a recursive descent parser; the core
>> of the evaluator is parse_op(), which uses a table to determine
>> operator behavior and precedence.
>>
>> All numeric values are represented as 'long', which is only 32 bits on
>> 32-bit hosts; it may be interesting to use 'long long' instead.
>
>
> Back when my timeconst perl removal patch was a shell script, it relied on
> 64 bit expr support and I got a busybox fix for that. Since then, I've
> rewritten it in C (and HPA rewrote it in bc), but it would probably be best
> to have it as 64 bit math anyway.

Okay, perhaps I will spin a patch for this if nobody else gets to it.

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

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

Thanks,
-- Daniel Verkamp