[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Arithmetic evaluation of negative numbers with base prefix

From: Chet Ramey
Subject: Re: Arithmetic evaluation of negative numbers with base prefix
Date: Fri, 14 Jun 2019 11:37:51 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

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    address@hidden    http://tiswww.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]