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

Bruce Evans brde at optusnet.com.au
Fri Jul 1 00:27:06 UTC 2011

On Thu, 30 Jun 2011, Stefan Esser wrote:

> Am 30.06.2011 18:46, schrieb 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.
> Yes, especially when you move them from e.g. amd64 to i386 ...
>> 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
> Yes, but it seems that intmax_t is guaranteed to be at least 64bit wide.

It was intentional to use intmax_t instead of int64_t.  This allows for
future expansion.  The range checking will detect unportabilities in
scripts that depend on intmax_t being even larger than int64_t, and
hopefully prevent existence of such scripts.

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

I don't think POSIX is that broken :-).

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

Behaviour on overflow is equally undefined.

>> 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.
> You cannot portably rely in overflow, since you have no guarantee that
> overflow occurs at a specific boundary.

And that is when it is implementation-defined.  FreeBSD's man page
attempts to say what the FreeBSD implementation definition is, but
ends up saying that the behaviour is undefined -- it says "will overflow
silently according to the rules of the C standard, using the long data
type", but the C standard says that the behaviour is undefined, and
"undefined" of course doesn't include silence.


More information about the freebsd-standards mailing list