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

Harald van Dijk wrote in
 <[email protected]>:
 |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/c4d6f1b1613c228db1e157a2136c53f5\
 |>|||5\
 |>|||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.

Ok, but i am not with you regarding that then.  (Do you can name
"other platforms"?)  I think the other shells are not either.
As a little bit laxe one regarding all that i want to point to
the email [1] (thread start [2], if you really want and do not
read it anyway), especially

  I hear and understand what you're saying. I think what I'm
  trying to point out, is that in C, as it was originally
  implemented, in expressions "a + b", "a >> 1", "++a", C
  "does what the machine does".  That's a very different thing
  from having rational, safe, predictable language semantics
  for operations on types - but it was also a strength, and a
  simple way to describe what C would do, deferring to machine
  semantics. I believe one place in C89/C90 where this is stated
  explicitly, as "do what the machine does"

  [1] https://www.tuhs.org/pipermail/tuhs/2025-August/032386.html
  [2] https://www.tuhs.org/pipermail/tuhs/2025-August/032381.html

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