From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18746 invoked from network); 17 Jun 2008 15:49:45 -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; 17 Jun 2008 15:49:45 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 84977 invoked from network); 17 Jun 2008 15:49:41 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 17 Jun 2008 15:49:41 -0000 Received: (qmail 6626 invoked by alias); 17 Jun 2008 15:49:38 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25201 Received: (qmail 6614 invoked from network); 17 Jun 2008 15:49:37 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 17 Jun 2008 15:49:37 -0000 Received: from prunille.vinc17.org (vinc17.pck.nerim.net [213.41.242.187]) by bifrost.dotsrc.org (Postfix) with ESMTP id 05ECE8028AC3 for ; Tue, 17 Jun 2008 17:49:33 +0200 (CEST) Received: by prunille.vinc17.org (Postfix, from userid 501) id 967C82350D6B; Tue, 17 Jun 2008 17:49:33 +0200 (CEST) Date: Tue, 17 Jun 2008 17:49:33 +0200 From: Vincent Lefevre To: Zsh hackers list Cc: Richard Hartmann , Peter Stephenson Subject: Re: arithmetic operator precedence Message-ID: <20080617154933.GS10734@prunille.vinc17.org> Mail-Followup-To: Zsh hackers list , Richard Hartmann , Peter Stephenson References: <2d460de70806170219k12ff4cadn441b52c48bf8076f@mail.gmail.com> <20080617094509.GC5016@sc.homeunix.net> <20080617111934.GE10734@prunille.vinc17.org> <20080617115742.GE5016@sc.homeunix.net> <20080617123551.GJ10734@prunille.vinc17.org> <20080617124607.GH5016@sc.homeunix.net> <20080617130246.GL10734@prunille.vinc17.org> <20080617132039.GK5016@sc.homeunix.net> <20080617143357.GO10734@prunille.vinc17.org> <20080617145338.GQ5016@sc.homeunix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20080617145338.GQ5016@sc.homeunix.net> X-Mailer-Info: http://www.vinc17.org/mutt/ User-Agent: Mutt/1.5.18-vl-r22984 (2008-06-11) X-Virus-Scanned: ClamAV 0.92.1/7494/Tue Jun 17 06:46:03 2008 on bifrost X-Virus-Status: Clean On 2008-06-17 15:53:38 +0100, Stephane Chazelas wrote: > On Tue, Jun 17, 2008 at 04:33:57PM +0200, Vincent Lefevre wrote: > [...] > > > which I understand as any occurrance of a variable name (other than > > > $-, $?, $0... obviously) in $((...)) should be the same as if the $ > > > was not ommited (when $x contains an integer constant). > > > > No, POSIX doesn't say that. This sentence is a mean to define the > > value of x from the contents of $x. But note that parsing has already > > been done and you have something like a C expression ("The arithmetic > > expression shall be processed according to the rules given in > > Arithmetic Precision and Operations"); variables are just replaced > > by their values, like in C. Without any extension, both interpretations > > are equivalent anyway. > > That's one interpretation. And that's the most intuitive one I can see. And that's why both bash and zsh follow this interpretation. > [...] > > Also ** is out of the scope of POSIX too. > > Yes, as I said I think clearly enough, if POSIX were to specify > ** _in a future version of the standard_, No, you said: "POSIX does say that $((a ** 2)) is the same as $(($a ** 2)) because $a contains an integer constant, and that's $((-3**2))." > it is more likely that it implements it as -3 ** 2 == 9, to avoid > confusion. That's your opinion. I'd say it is very unlikely to regard $((a ** 2)) as $(($a ** 2)) because 1. It is very confusing (more precisely, the $(($a ** 2)) form is confusing as far arithmetic evaluation is concerned, and that's probably why the form with variables in arithmetic expressions have been added). 2. Several shells (bash, zsh) do it in another way, and AFAIK, no-one has complained on their behavior. > - because it doesn't at the moment clearly state how bare > variable names are to be interpreted as you point out (it's true > that I was interpreting maybe a bit too much) As it does a reference to C expressions, I'd say that it should do like C. Note that with your interpretation, two passes are necessary if the shell regards advanced forms of integer constants (such as "1 + 1"): one to identify the variable names, and one to reparse the expression after replacing the variable names. > - because it doesn't clearly state whether -3 is an integer > constant or not. ash allows a=-3; echo $((a * 3)) while it > doesn't allow a=0-3; echo $((a * 3)) for instance. But then, > given that a negative number can be the result of an > arithmetic expansion, I can't see how it can be interpreted in > any other way than -3 is an integer constant. Yes, that's why it's probably a bug (but POSIX doesn't even say that the shell should be able to re-read the output value). > - because all existing shell implementations do it that way at > the moment. Only for precedence reasons (probably without much reflection and because the unnecessary precedence of the unary - over * was already there), certainly not because $((a ** 2)) and $(($a ** 2)) are regarded as the same: they are handled differently. BTW, when using directed rounding modes, this is very confusing in C. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)