Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Jeremy Townshend <jeremy.townshend@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: Arithmetic evaluation of negative numbers with base prefix
Date: Mon, 17 Jun 2019 14:30:27 +0100
Lines: 48
Approved: bug-bash@gnu.org
Message-ID: <mailman.275.1560778236.10840.bug-bash@gnu.org>
References: <20190614141947.GB27242@tower> <dc253e63-de07-6c60-7b20-1688286a43d2@case.edu> <20190617133026.GC27242@tower>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: bug-bash@gnu.org, bash@packages.debian.org
To: Chet Ramey <chet.ramey@case.edu>
Envelope-to: bug-bash@gnu.org
Content-Disposition: inline
In-Reply-To: <dc253e63-de07-6c60-7b20-1688286a43d2@case.edu>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: list
Xref: csiph.com gnu.bash.bug:15051

Dear Chet

Many thanks for your impressively swift response.  It is enlightening to see
how these expressions are parsed.

For the record, whilst I can now see how they are parsed, it feels
particularly unsatisfactory that the following two expressions yield the same
result when the variable i happens to have unwittingly been decremented below
zero (by bash arithmetic evaluation by the way - not by the output of some
external command):

  echo $((3-10#${i})) 
  echo $((3+10#${i})) 

As you indicate, this is caused by 10# being parsed as zero.  That silent
assumption of zero effectively then also silently nullifies/swallows the
preceding operator.

Ilkka Virta's email helpfully pointed me to a somewhat related debate that
occurred about 11 months ago.  I agree with your comment in this debate:

  "There would be a good case for rejecting the '10#' because it's missing
  the value."

It is this silently proceeding with a plausible (but undesirable) output in
such cases which is especially concerning.

In the meantime it would seem cautionary to advise against the pitfall of
using base# prefixed to variables (contrary to
mywiki.wooledge.org/ArithmeticExpression) unless you can be confident that
they will never be decremented below zero.

At the very least it would be helpful if the manual reflected that 10#
followed by anything other than a digit ([0-9a-zA-Z@_]) is parsed as zero, and
rlarified more completely the constraints of "number" for "n" in the "base#"
paragraph.  

I cannot find anywhere else in the manual where the word "number", "numeric
value" or "integer" excludes values less than zero without explicitly stating
so.  On the other hand phrases like "[if] ...  number/numeric values less than
zero", "if ...  [not] a number greater than [or equal to] zero" are used
repeatedly.  In those cases "number" clearly doesn't exclude those less than
zero.


Jeremy Townshend