Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #15049 > unrolled thread

Re: Arithmetic evaluation of negative numbers with base prefix

Started byChet Ramey <chet.ramey@case.edu>
First post2019-06-14 11:37 -0400
Last post2019-06-14 11:37 -0400
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Arithmetic evaluation of negative numbers with base prefix Chet Ramey <chet.ramey@case.edu> - 2019-06-14 11:37 -0400

#15049 — Re: Arithmetic evaluation of negative numbers with base prefix

FromChet Ramey <chet.ramey@case.edu>
Date2019-06-14 11:37 -0400
SubjectRe: Arithmetic evaluation of negative numbers with base prefix
Message-ID<mailman.87.1560526725.10840.bug-bash@gnu.org>
On 6/14/19 10:19 AM, Jeremy Townshend wrote:

> Bash Version: 4.4
> Patch Level: 19
> Release Status: release
> 
> Description:
> 	Unexpected and undocumented behaviour for arithmetic evaluation of negative numbers when prefixed with the optional "base#" (e.g. 10#${i}). The base prefix may be needed if the variable has a decimal integer value but might be zero-padded, otherwise it is at risk of being misinterpreted as an octal.  Where the variable holds a negative value, results are as you would expect (e.g. i=-1; echo $((10#${i})), returns -1) until you subtract (or unary minus) the variable.  This unexpected behaviour occurs even when numbers are used directly (as in the first part of the Repeat-By section to simplify) but in real world examples the number would be hidden in a variable requiring the optional "base#" prefix to ensure correct interpretation of its value. 

I think the issue is that unary minus is an operator, not part of an
integer constant. That affects how expressions are parsed.

Couple that with the shell's arithmetic evaluator being helpful and
treating 10# as identical to 10#0, you can see how the results you
mark as `unexpected' are straightforward results of operator parsing.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web