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

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.

So here and for my thing you now have a credit (not the first, you
are already in THANKS), for that UBSAN fix, less mentioned modulo.

Ciao,

--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)