Re: Arithmetic expression: interest in unsigned right shift?

[Martin D Kealey]

Printf %u already reveals  the word size, as do most kinds of overflow -
albeit messily, like $((3**40))

At least by explicitly exposing the word size in a controlled manner, we
can write code that avoids unintended overflow.

-Martin

On Sun, 17 Jul 2022, 11:54 Dale R. Worley, <worley@alum.mit.edu> wrote:

> Steffen Nurpmeso <steffen@sdaoden.eu> writes:
> > I realized there is no unsigned right shift in bash arithmetic
> > expression, and thought maybe there is interest.
>
> This would be difficult to define cleanly.
>
> Currently, arithmetic values are considered to be signed, and >>
> operates on them as such.  So
>
>     $ echo $(( 1 >> 1 ))
>     0
>     $ echo $(( 2 >> 1 ))
>     1
>     $ echo $(( 3 >> 1 ))
>     1
>     $ echo $(( (-1) >> 1 ))
>     -1
>     $ echo $(( (-2) >> 1 ))
>     -1
>     $ echo $(( (-3) >> 1 ))
>     -2
>     $ echo $(( (-4) >> 1 ))
>     -2
>     $
>
> For positive values, unsigned right shift would be the same as >>.  But
> for negative numbers, the value has to be cast into an unsigned value,
> which is then right-shifted (equivalently, divided by a power of 2), and
> the resulting value then has to be cast back into a signed value.
>
> But that will depend on (reveal) the word length of Bash arithmetic
> computation:  (-1) >>> 1 will be equal to 2#01111...1111, which prints
> as a positive number.  In contrast the current Bash arithmetic model is
> "word-length agnostic as long as you don't overflow", it acts as if the
> values are mathematical integers.
>
> Dale
>
>