Re: Arithmetic evaluation of negative numbers with base prefix

[Jeremy Townshend]

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