From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22251 invoked from network); 19 Jun 2008 16:21:02 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.4 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 19 Jun 2008 16:21:02 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 15743 invoked from network); 19 Jun 2008 16:20:59 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 19 Jun 2008 16:20:59 -0000 Received: (qmail 6734 invoked by alias); 19 Jun 2008 16:20:55 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25219 Received: (qmail 6719 invoked from network); 19 Jun 2008 16:20:55 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 19 Jun 2008 16:20:55 -0000 Received: from mail.o2.co.uk (yoda.london.02.net [82.132.130.151]) by bifrost.dotsrc.org (Postfix) with ESMTP id C85078084FA1 for ; Thu, 19 Jun 2008 18:20:37 +0200 (CEST) Received: from sc.homeunix.net (78.105.216.138) by mail.o2.co.uk (8.0.013.3) (authenticated as stephane.chazelas) id 4851DD9501366F9A; Thu, 19 Jun 2008 17:20:37 +0100 Received: from chazelas by sc.homeunix.net with local (Exim 4.69) (envelope-from ) id 1K9MsG-0006mp-Kk; Thu, 19 Jun 2008 17:20:36 +0100 Date: Thu, 19 Jun 2008 17:20:36 +0100 From: Stephane Chazelas To: zsh-workers@sunsite.dk, "Jun T." Subject: Re: arithmetic operator precedence Message-ID: <20080619162036.GF5016@sc.homeunix.net> Mail-Followup-To: zsh-workers@sunsite.dk, "Jun T." References: <2d460de70806170219k12ff4cadn441b52c48bf8076f@mail.gmail.com> <20080617094509.GC5016@sc.homeunix.net> <2d460de70806170324o5a44609x9383cc2445d67dd6@mail.gmail.com> <20080617103829.GD5016@sc.homeunix.net> <20080617114340.398c731f@news01> <20080617112815.GF10734@prunille.vinc17.org> <200806171146.m5HBkhfR013230@news01.csr.com> <20080619095454.GE5016@sc.homeunix.net> <20080619160024.GK10734@prunille.vinc17.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20080619160024.GK10734@prunille.vinc17.org> User-Agent: Mutt/1.5.16 (2007-09-19) X-Virus-Scanned: ClamAV 0.92.1/7506/Thu Jun 19 16:51:14 2008 on bifrost X-Virus-Status: Clean On Thu, Jun 19, 2008 at 06:00:24PM +0200, Vincent Lefevre wrote: > On 2008-06-19 10:54:54 +0100, Stephane Chazelas wrote: > > With all the existing operators, one can do > > > > x=$(( some-expression )) > > y=$(( some-other-expression )) > > z=$(( $x $y )) > > > > and it's OK whatever some-expression and some-other-expression > > and as long as they are POSIX. > > This is not guaranteed to work. Indeed POSIX allows constants other > than the "canonical" ones to be recognized. With such constants, > you can get wrong results. Whether such constants can occur for some > reason is another matter. In *practice*, it is safer to write: > > z=$(( ($x) ($y) )) > > and even safer to write: > > z=$(( x y )) > > though it may not work in non-POSIX shells. I'm under the impression your misunderstand the purpose of POSIX. POSIX is a tool to help people write portable applications (when it comes to shells, that means _scripts_). You cannot write z=$(( x y )) in a POSIX script, because the result is unspecified. z=$(($x $y)) is specified (with the conditions I detailed). If in your script, you make sure $x and $y are integer constants (as in [-+]?(0[xX][a-fA-F0-9]+|0[0-7]+|[1-9][0-9]*)), then it will work as expected. If $x and $y are valid arithmetic expressions that may not be integer constants as described above, then you need: z=$((($x) ($y))) But I wouldn't do such things in a script. My example was about $x and $y being the result of arithmetic expansions. [...] > Shells should be designed to work *in practice* (and do what the > user expects to get), not to work specifically on theoretical > implementations that will never exist. [...] POSIX is not about a theoretical implementation. It's the specification of an API or a language if you like. Just like the C spec doesn't specify a theoretical compiler, but a language. Of course, someone who wants to design a C compiler must refer to that spec, but the main target of that spec is people writing C code. -- Stéphane