Date: Thu, 30 Jun 2011 13:52:54 -0400 From: Garrett Wollman <wollman@csail.mit.edu> 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: <19980.47094.184089.398324@khavrinen.csail.mit.edu> 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 19:06:03 +0200, Stefan Esser <se@freebsd.org> said: > Well, that's the frustrating part: I had implemented 64bit range in expr > back in 2000, but this extended range (on 32bit archs) has been made > optional, some two years later with the commit message you quote. The 2001 POSIX standard states: > Integer variables and constants, including the values of operands > and option-arguments, used by the standard utilities listed in this > volume of IEEE Std 1003.1-2001 shall be implemented as equivalent to > the ISO C standard signed long data type; floating point shall be > implemented as equivalent to the ISO C standard double > type. Conversions between types shall be as described in the ISO C > standard. All variables shall be initialized to zero if they are not > otherwise assigned by the input to the application. > Arithmetic operators and control flow keywords shall be implemented > as equivalent to those in the cited ISO C standard section, as > listed in Table 1-2 (on page 8). However, for arithemtic expansion in the shell (but *not* the expr utility), it says: > As an extension, the shell may recognize arithmetic expressions > beyond those listed. The shell may use a signed integer type with a > rank larger than the rank of signed long. The shell may use a > real-floating type instead of signed long as long as it does not > affect the results in cases where there is no overflow. The language in the 2008 version of the standard is the same. For expr, the following definitions are relevant (from XCU7 page 2715): > integer An argument consisting only of an (optional) unary minus > followed by digits. > string A string argument; see below. [...] > A string argument is an argument that cannot be identified as an > integer argument or as one of the expression operator symbols shown > in the OPERANDS section. I'm unable to find the response to my interpretation request in the Austin Group mail archives. -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980.47094.184089.398324>