Arithmetic expansion bug.
Description: There is a bug when expanding this math: $ echo "$((~0))" bash: /home/user: syntax error: operand expected (error token is "/home/user") It works correctly when an space is added: $ echo "$(( ~0 ))" -1 Bash version: $ echo "$BASH_VERSION" 4.4.12(1)-release 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-7fckc0/bash-4.4=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -no-pie -Wno-parentheses -Wno-format-security uname output: Linux IO.iafcg.priv 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (2018-01-14) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.4 Patch Level: 12 Release Status: release -- Cases are always threesome: Best case, Worst case, and Just in case
Number with sign is read as octal despite a leading 10#
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 uname output: Linux IO 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.4 Patch Level: 12 Release Status: release Description: A value inside an arithmetic expansion is processed as octal despite using a 10# preffix. Repeat-By: $ echo $((10#+0034)) 28 Fix: Extract optional sign before parsing the number, re-attach after. -- Cases are always threesome: Best case, Worst case, and Just in case
Re: Number with sign is read as octal despite a leading 10#
Chet Ramey () wrote: > On 7/10/18 2:48 PM, Isaac Marcos wrote: > > That is not an integer constant. Integer constants don't begin with > `-'. > That makes negative numbers invalid. This is not a serious argument. Because of the difference between an operator and a constant. Unary plus > and minus have a higher precedence than arithmetic operators. So if you > expand the `a' to an expression, which is what happens, the expression > consists of an operator (+ or -) and a constant, and that expression has > a higher precedence than the +. You might think about why using `$a' in > place of the `a' would not work all the time. > I don't care. All other shells do this correctly. It makes you the only one wrong. This is not a serious discussion. -- Cases are always threesome: Best case, Worst case, and Just in case
Re: Number with sign is read as octal despite a leading 10#
2018-07-10 18:12 GMT-04:00 Eduardo Bustamante : > On Tue, Jul 10, 2018 at 1:57 PM, Isaac Marcos > wrote: > > Chet Ramey () wrote: > [..] > > This is not a serious argument. > [...] > > I don't care. All other shells do this correctly. It makes you the only > one > > wrong. > > > > This is not a serious discussion. > > Can you keep the discussion civil? No. > I don't get why you feel compelled > to qualify an argument from the main developer as "non serious". > Because *he* qualified my comments as "non serious" in another email. > What's your definition of "correct"? Exactly what was posted on the fist post. That a `a=+0034; echo "$((10#$a))"' print 34 not 28. Try this(from some other e-mail I did send): set -- 34 034 0034 +34 +034 +0034 -34 -034 -0034 ; for i do printf '%6s' "$((10#$i))"; shift; done; echo 343434342828 -34 -28 -28 # bash 343434342828 -34 -28 -28 # posixbash 343434343434 -34 -34 -34 # lksh 343434343434 -34 -34 -34 # mksh 343434343434 -34 -34 -34 # ksh93 343434343434 -34 -34 -34 # attsh 343434343434 -34 -34 -34 # zsh Only bash prints 28. Why others can print 34 ? According to Chet, the definition > is the same as the ISO C standard. I'm not sure if there's a public > version of the ISO C standard document, but > http://c0x.coding-guidelines.com/6.4.4.1.html seems to be good enough. > The definition of an "integer constant" in that document does not > include a sign. > That is a description of the inability (or unwillingness) to raise above c limitations. What is odd in expecting that an string like `-00133` actually mean `-133` in decimal? Even more if the shell is explicitly told to parse the string as decimal with the `10#'. > So, in that regard, Bash is behaving according to specification. > As is also according to specification (of c) that a string could not have a NUL byte but some shells raise above that limit and are able to reasonably use such values. But I don't care anymore. This is the way in which users are lost, and you have lost me. I'll just use some other shell. -- Cases are always threesome: Best case, Worst case, and Just in case
Re: Number with sign is read as octal despite a leading 10#
According to Chet, the definition > is the same as the ISO C standard. I'm not sure if there's a public > version of the ISO C standard document, but > http://c0x.coding-guidelines.com/6.4.4.1.html seems to be good enough. > The definition of an "integer constant" in that document does not > include a sign. > > That is a description of the inability (or unwillingness) to raise above c limitations. Let me state that even better. That's like saying that because the only tool known is a hammer, then, using an screw is not possible with a hammer and therefore it is a bad idea to invent one. Just silly. > I'll just use some other shell. > > -- Cases are always threesome: Best case, Worst case, and Just in case
Re: Number with sign is read as octal despite a leading 10#
Chet Ramey (mailto:chet.ra...@case.edu>>) wrote: > It doesn't matter. Unary plus and minus are operators, not part of integer constants. But you are confused, what is after the 10# is not an integer constant, it is an string. An string that is being parsed by bash C code and coerced into a sign operator and a string of digits. What causes the problem is that the sign breaks the effect of the 10#. But that is entirely the result of the chosen interpretation of the string. You claim that it should be as the c language does it. But that is in conflict with any common human interpretation, namely: A number is: An optional sign followed by one or more digits. If you don't want to agree then mark this bug as wont-fix. El mar., 10 jul. 2018 a las 23:31, Chet Ramey () escribió: > On 7/10/18 6:46 PM, Isaac Marcos wrote: > > 2018-07-10 18:12 GMT-04:00 Eduardo Bustamante > <mailto:dual...@gmail.com>>: > > > > On Tue, Jul 10, 2018 at 1:57 PM, Isaac Marcos > > mailto:isaacmarcos100...@gmail.com>> > wrote: > > > Chet Ramey (mailto:chet.ra...@case.edu>>) > wrote: > > [..] > > > This is not a serious argument. > > [...] > > > I don't care. All other shells do this correctly. It makes you the > only one > > > wrong. > > > > > > This is not a serious discussion. > > > > Can you keep the discussion civil? > > > > > > No. > > > > > > I don't get why you feel compelled > > to qualify an argument from the main developer as "non serious". > > > > > > Because *he* qualified my comments as "non serious" in another email. > > I did. You wrote: > > "Are you saying that bash should reject the use of negative numbers? > And, If so, why bash does not raise an error? (as it is expected that it > must do on invalid input)." > > This is clearly a ridiculous strawman. > > The topic is whether or not a sign can appear in the middle of an integer > constant, even when that integer constant begins with the `base#' syntax. > > > Only bash prints 28. Why others can print 34 ? > > They extend the definition of an integer constant. It's perfectly > reasonable to do that. Bash sticks to the C definition. > > > > > What is odd in expecting that an string like `-00133` actually mean > `-133` > > in decimal? > > Why would that be reasonable? Integers beginning with `0' are octal > constants. > > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ > -- Cases are always threesome: Best case, Worst case, and Just in case
