Fwd: [RFC] Consistent numeric range for "expr" on all architectures

[David Schultz]

On Wed, Jun 29, 2011, Stefan Esser wrote:
> My suggestion is to make the following modifications to expr:
> 
> 1) Always compute with 64 bit range and overflow checks enabled. This
>    means, that the "-e" option is always assumed.
> 
> 2) Continue to support the "-e" option as a NOP for compatibility with
>    scripts that knew about that FreeBSD extension.

Using 64-bit signed integer arithmetic consistently in expr sounds
like a reasonable idea.  There's no reason shell scripts ought to
be exposed to architectural details.

There are two problems, however.  First, the implementation
doesn't do this: it uses intmax_t, which has platform-dependent
width, at least in theory.  Second, it sounds like POSIX doesn't
allow this (although I don't know where this requirement comes
from):

| r96367 | wollman | 2002-05-10 18:59:29 -0400 (Fri, 10 May 2002) | 5 lines
| 
| The response to my POSIX interpretation request says that `expr'
| is required to be oblivious to overflow and to use the data type `long'.
| (Division by zero is undefined in ISO C so it's still OK to check for it
| here.)  Add a new `-e' flag to get the old, more useful behavior.

Nevertheless, moving to int64_t arithmetic by default seems like a
good idea, with low potential for complications.

Overflow checking is a separate concern, and one that is more
likely to cause problems.  I'd be more careful about changing the
default behavior there, because some scripts might rely on modular
arithmetic without overflow checks.

Another thing that is likely to cause confusion is expr(1)
behaving differently from the shell builtin, and differently from
the shell's arithmetic.  Above all else, I suggest trying to make
everything consistent...perhaps talk to jilles@ about the shell
side of things.