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, <wor...@alum.mit.edu> wrote: > Steffen Nurpmeso <stef...@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 > >
