Re: [PATCH] left shift of negative value do_binop src/arith_yacc.c:111:12

On 20/08/2025 13:14, Steffen Nurpmeso wrote:
> Steffen Nurpmeso wrote in
>   <20250820113344.cw2oHltI@steffen%sdaoden.eu>:
>   |Steffen Nurpmeso wrote in
>   | <20250820112753.FJo-4m6j@steffen%sdaoden.eu>:
>   ||Harald van Dijk wrote in
>   || <[email protected]>:
>   |||On 20/08/2025 01:33, Aleksander Ushakov wrote:
>   |||> Well, if we take bash with UBSAN instrumentation and try to use a
>   | ...
>   |||I did that in my own version back in 2019, with the exception of subtly
>   | ...
>   |||<https://github.com/hvdijk/gwsh/commit/c4d6f1b1613c228db1e157a2136c53f55\
>   |||b4530c8>.
>   |||As those commits show, there are quite a few more cases to consider than
>   |||left shifts of negative values.
>   ||
>   ||We (i am only a MUA though, since busybox did not take the code,
>   ||and kept their broken implemenation; will try again at some time)
>   ||all return -2 for "-1 << 1", at least on this hardware etc etc.
>   ||You then return 0 from looking at the commitdiff!?!
>   |
>   |ah no forget that rubbish, the test is about rval.
> 
> Ah.  However, may i suggest one thing?  You test against
> "(uintmax_t) b >= INTMAX_WIDTH)" and say "excessive
> shift counts do not lose the high bits".
> On at least x86 (where i have been educated) excessive shift
> counts are reduced to &(bits-1) aka %BITS_OF_XY_INT.  I have no
> overview on how other platforms do it, plus i have forgotten
> whether that behaviour is possibly standardized by any language.
> But i am used to that, and am possibly not alone with this.
This is what I was referring to with "subtly changing behaviour that 
differed across architectures". This behaved differently across 
architectures, taking only the low bits of the shift count is what x86 
does but is not universal, and I did not think it would be sensible to 
implement that on other platforms where it never worked that way. The 
behaviour I picked is what would have been the result if excessive shift 
counts hadn't been explicitly undefined, it's simply that e.g. a shift 
by 123 is equivalent to 123 shifts by 1.

Cheers,
Harald van Dijk