[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-standards
Subject:    Re: Fwd: [RFC] Consistent numeric range for "expr" on all
From:       Bruce Evans <brde () optusnet ! com ! au>
Date:       2011-07-01 0:27:03
Message-ID: 20110701100701.U1279 () besplex ! bde ! org
[Download RAW message or body]

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
_______________________________________________
freebsd-standards@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-standards
To unsubscribe, send any mail to "freebsd-standards-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]