From owner-freebsd-standards@FreeBSD.ORG Thu Jun 30 17:18:59 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 74F4C106566C for ; Thu, 30 Jun 2011 17:18:59 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm30.bullet.mail.sp2.yahoo.com (nm30.bullet.mail.sp2.yahoo.com [98.139.91.100]) by mx1.freebsd.org (Postfix) with SMTP id 580618FC1A for ; Thu, 30 Jun 2011 17:18:59 +0000 (UTC) Received: from [98.139.91.67] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 30 Jun 2011 17:06:08 -0000 Received: from [98.136.185.47] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 30 Jun 2011 17:06:08 -0000 Received: from [127.0.0.1] by smtp108.mail.gq1.yahoo.com with NNFMP; 30 Jun 2011 17:06:08 -0000 X-Yahoo-Newman-Id: 913956.36989.bm@smtp108.mail.gq1.yahoo.com Received: from [192.168.119.20] (se@81.173.186.241 with plain) by smtp108.mail.gq1.yahoo.com with SMTP; 30 Jun 2011 10:06:06 -0700 PDT X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-YMail-OSG: QxSXANIVM1njiZAbBuil7_IdtFmU6BPtQApEsK6n6bG2zXU Wg8scr_X1q8JtnZCRtyWOTTZ_Pu8kmZ2glahJLLcKyZPaRaiVKjZigVAu_rl eeKaCR0v3X1Nw.kD9AqpUn0iSj3AsYL9vuIRJT5W7Cme7Oqao_tPkzxA0wEW ILapMHU_854MxKoqAaZjzfzvJud2_a33c492KEHM.sIbCW324mBlq5mZT3In mYXjmTxRcH5dHg3XGhbQSPbucJDQXHtkaEuOebn3HgAIDKt2wvaRrzMxwW49 zfhGRazFsC.8imzswD4kKNfLSEHO9IeBMzpNlLR3FHBopeBdsrcB5EUoK.Tg Bx9AQ77tEBDqo8DYwQ__SHhscSw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4E0CACFB.8040906@freebsd.org> Date: Thu, 30 Jun 2011 19:06:03 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-standards@freebsd.org References: <4E09AF8E.5010509@freebsd.org> <4E0B860E.50504@freebsd.org> <20110630164653.GA82980@zim.MIT.EDU> In-Reply-To: <20110630164653.GA82980@zim.MIT.EDU> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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:18:59 -0000 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. > 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'. > | (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. 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. In between, a number of people were hurt by scripts that silently truncated numeric operands or results, and during a mail exchange in that context, the above requirement was said to not really apply. The reasoning is, that overflow beyond the range of signed long leads to unspecified behaviour. And one possibility to deal with unspecified behaviour it to just return the "correct" result without wrap-aroung. The range check is also possible in that case, AFAIK. Once you are outside the specified range, POSIX allows extensions that do just what I propose (and what already was in FreeBSD, 10 years ago). > Nevertheless, moving to int64_t arithmetic by default seems like a > good idea, with low potential for complications. On amd64 and other 64 bit architectures the numeric range already is 64bit. > 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. > 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 ...). But there is no expr builtin anymore, so there is no risk here ;-) Regards, STefan