From owner-freebsd-standards@FreeBSD.ORG Thu Jun 30 17:42:09 2011 Return-Path: Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BE8C106564A; Thu, 30 Jun 2011 17:42:09 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 8828A8FC14; Thu, 30 Jun 2011 17:42:08 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.4/8.14.2) with ESMTP id p5UHg8VQ083790; Thu, 30 Jun 2011 13:42:08 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.4/8.14.2/Submit) id p5UHg8FI083789; Thu, 30 Jun 2011 13:42:08 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 30 Jun 2011 13:42:08 -0400 From: David Schultz To: Stefan Esser Message-ID: <20110630174208.GA83700@zim.MIT.EDU> Mail-Followup-To: Stefan Esser , freebsd-standards@freebsd.org References: <4E09AF8E.5010509@freebsd.org> <4E0B860E.50504@freebsd.org> <20110630164653.GA82980@zim.MIT.EDU> <4E0CACFB.8040906@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E0CACFB.8040906@freebsd.org> Cc: freebsd-standards@FreeBSD.ORG Subject: Re: Fwd: [RFC] Consistent numeric range for "expr" on all architectures X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 17:42:09 -0000 On Thu, Jun 30, 2011, Stefan Esser wrote: > Am 30.06.2011 18:46, schrieb David Schultz: > > 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. The distinction is that int64_t is always exactly 64 bits, whereas intmax_t could be wider. If the goal is to guarantee that expr's arithmetic is architecture-independent, then int64_t is a more appropriate type. (This requires a narrowing conversion and range check after strtoimax(), but the compiler should optimize it away.) > > 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. My point was that some scripts might rely on the lack of overflow checking anyway. This is a separate and potentially more problematic change. But I'm not trying to argue that it's necessarily a bad idea. > > Another thing that is likely to cause confusion is expr(1) > > behaving differently from the shell builtin, and differently from > > the shell's arithmetic. Above all else, I suggest trying to make > > everything consistent...perhaps talk to jilles@ about the shell > > side of things. > > My change in 2000 made the shell builtin do 64bit arithmetic as well (in > fact, the shell build just included the expr.y file ...). I don't know the state of the shell these days. Didn't jilles@ change the shell to do that more recently? My point here is that working to make both the shell and expr behave identically would be ideal.