Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-vEMnMR/bash-4.4.18=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname output: Linux tower 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49
UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
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.
Repeat-By:
echo $((10#-1)) # -1 as expected
echo $((0-10#1)) # -1 as expected
echo $((0+10#-1)) # -1 as expected
echo $((0-10#-1)) # -1 UNEXPECTED. Would expect 1.
echo $((0--1)) # 1 as expected
# Real world example:
i=001
echo $((3-10#${i})) # 2 as expected
i=$((10#${i}-2)) # i's value decremented by 2 to -1
echo $((3-10#${i})) # 2 UNEXPECTED. Would expect 4.
echo $((3+10#${i})) # 2 as expected
# Certainly wouldn't expect the last two expressions to have the same
# result.
