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.
Bruce
More information about the freebsd-standards
mailing list