bug#43764: Calc shift right broken

["Mattias Engdegård" <mattiase@acm.org>]

4 nov. 2020 kl. 12.14 skrev Vincent Belaïche <vincent.b.1@hotmail.fr>:

> I can see no reason why modulo form would need some special nil case, and I suspect that at some point of time the bit-width clipping could be disabled by setting the width to nil. So now, don't we have two conventions in the code : 0 and nil.

From my reading of math-binary-modulo-args, the word width (w) isn't tested because calc-word-size can be nil, but because it may be passed as an optional argument. See calcFunc-and for an example.

> Also, I noticed that the Calc test suite does not have any test case (or I missed it) for binary operations + modulo forms.

The Calc test suite is minimal and mostly consists of regression tests added when fixing bugs during the last year or so. The vast bulk of Calc remains untested. Contributions are welcome!

> Also, concerning your comment about the rotate right by n bits of numbers with non zero least significant n bits, and with disabled bit width clipping, Calc has the infinite mode (press 'm i'), so if you decide some day to make this sort of implementation, then you should emit an error w/o infinite mode, but have a +inf with infinite mode. A bit (n-1) equal to 1 won't cause any -inf, because two complement signing is not possible with disabled bit width clipping, as this would result in an infinite number of FFFFFF with negative finite numbers.

My remarks were probably not very well thought out, sorry. Infinities and bitwise operations seem difficult to reconcile in general; for example, (+inf AND 1) is undefined. Any extension to include ±inf would need better underpinning than my feeble attempt.

Note however that with disabled bit width, negative numbers do in fact have an infinite number of leading ones, just as nonnegative numbers have an infinite numbers of leading zeros. This is just how two's complement works when there is no limited word size, and it doesn't involve actual infinites.

> I also notice that when two's complement signing display is on (type 'O d 6'), and bit width is set to 0 to disable bit width clipping, then the signing display is done as if the TwosComp mode was off. I think that it is OK to do that, but when 'b w 0 RET' or 'O d 6' is pressed, which ever comes last, and we have this conflict, then a warning message should be emitted, something like « Twos complement sign display is ignored when bit word width is not specified ».

Yes, there are probably edge cases where usability can be improved, but it didn't seem to involve actual errors or user deception so I didn't bother do more work than necessary.

Thank you very much for your remarks!