Date: Fri, 1 Jul 2011 10:27:03 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Stefan Esser <se@freebsd.org> Cc: freebsd-standards@freebsd.org Subject: Re: Fwd: [RFC] Consistent numeric range for "expr" on all architectures Message-ID: <20110701100701.U1279@besplex.bde.org> In-Reply-To: <4E0CACFB.8040906@freebsd.org> References: <4E09AF8E.5010509@freebsd.org> <4E0B860E.50504@freebsd.org> <20110630164653.GA82980@zim.MIT.EDU> <4E0CACFB.8040906@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110701100701.U1279>