[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Arithmetic expression: interest in unsigned right shift?
From: |
Martin D Kealey |
Subject: |
Re: Arithmetic expression: interest in unsigned right shift? |
Date: |
Sun, 17 Jul 2022 14:13:16 +1000 |
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
>
>