bug#43764: Calc shift right broken

[Mattias Engdegård]

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!