Re: $(( )): binary/unary VAR/NUM inconsistency

[Steffen Nurpmeso]

Hello!

Chet Ramey wrote in
 <1d592238-69c5-88b6-6e08-5d56e3170216@case.edu>:
 |On 7/6/22 1:10 PM, Steffen Nurpmeso wrote:
 ...
 |> I stumbled upon this (bash 5.1.16); i find it "understandable" in
 |> respect to clarity, but inconsistent, and also in hindsight to the
 ...
 |Thanks for the report. Most of these are due to bash trying to be helpful.
 |The pre/postfix operators are parsed as such when they make sense depending
 |on what precedes or follows them. For instance, if you have ++I, it's
 |parsed as a pre-increment; if you have ++1, it's parsed as two unary plus
 |operators and an integer constant.
 |
 |(Part of this was an attempt to be backwards compatible when I added the
 |++ and -- operators, since they weren't present until bash-2.04.)
 |
 |> 
 |>    $ bash -c 'I=10;echo "<$(( +10+++I ))>"'
 |>    <21>
 |
 |unary plus, constant, binary plus operator, pre-increment, variable
 |
 |>    $ bash -c 'I=10;echo "<$(( +10+ ++I ))>"'
 |>    <21>
 |
 |same
 |
 |>    $ bash -c 'I=10;echo "<$(( +10+ +I ))>"'
 |>    <20>
 |
 |unary plus, constant, binary plus operator, unary plus, variable

Funnily my parser has only one (what i know) problem left, the
same as bash.  On the other hand i found more.

[
    # make this work with (ba)sh \
    command -v shopt && shopt -s expand_aliases;\
    alias p=printf;alias e=echo;alias s=export
    #
    s I=10 J=33
]

  e "<$((  3          +           (      11       )  ))>"
  s I=10 J=33;p "<$(( +10 + + +I ))>";e "<$I>"
  s I=10 J=33;p "<$(( +10 + ++I ))>";e "<$I>"
  s I=10 J=33;p "<$(( +10 ++ +I ))>";e "<$I>"
  s I=10 J=33;p "<$(( +10 +++ I ))>";e "<$I>"
  s I=10 J=33;p "<$(( +10+++I ))>";e "<$I>"

And diff -u10 OUT .nail/y/t.wysh-arith-good

   <14>
   <20><10>
   <21><11>
   <20><10>
  -<21><11>
  +<20><10>
   <21><11>

I find bash less consistent, my thought was "either whitespace
matters, then it matters, or not".  (My first version removed
_all_ whitespace before parsing started, which was a failure.) 

And one more thing.

  -<802379605485813759>
  +<9223372036854775807>

This is from 

  $ bash -c 'echo $((999999999999999999999999999999999999999999999))'
  802379605485813759
  $ dash -c 'echo $((999999999999999999999999999999999999999999999))'
  9223372036854775807
  $ busybox.static sh -c \
    'echo $((999999999999999999999999999999999999999999999))'
  0
  $ MXEXE -#:/ \
    -Y 'echo $((999999999999999999999999999999999999999999999))' \
    -Yx
  9223372036854775807

(But

  $ bash -c 'echo $((0x8000000000000000))'
  -9223372036854775808
  $ dash -c 'echo $((0x8000000000000000))'
  9223372036854775807
  $ busybox.static sh -c 'echo $((0x8000000000000000))'
  -9223372036854775808
  $ MXEXE -#:/ -Y 'echo $((0x8000000000000000));x'
  -9223372036854775808

and

  $ MXEXE -#:/ -Y 'echo $((0xFFFFFFFFFFFFFFFF));x'
  -1
  $ dash -c 'echo $((0xFFFFFFFFFFFFFFFF))'
  9223372036854775807
  $ bash -c 'echo $((0xFFFFFFFFFFFFFFFF))'
  -1
  $ busybox.static sh -c 'echo $((0xFFFFFFFFFFFFFFFF))'
  -1

and

  $ busybox.static sh -c 'echo $((0xFFFFFFFFFFFFFFFF1))'
  0
  $ bash -c 'echo $((0xFFFFFFFFFFFFFFFF1))'
  -15
  $ dash -c 'echo $((0xFFFFFFFFFFFFFFFF1))'
  9223372036854775807
  $ MXEXE -#:/ -Y 'echo $((0xFFFFFFFFFFFFFFFF1));x'
  9223372036854775807

bash explicitly documents "no overflow checking", and things are
very wild in general.  My thoughts were 64-bit signed integer, but
for known power-of-two bases, which are parsed as unsigned, then
stored as signed 64-bit.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)