[m-dev.] for review: change semantics of integer shifts

[Zoltan Somogyi]

Fergus wrote:
> Also, I don't think it's quite right to say that the semantics of `>>'
> and `<<' have changed.  Really we've just clarified the previously
> unclear documentation, and fixed the implementation so that it correctly
> implements the documentation.  If you say that the semantics have changed,
> people might think that there is some compatibility issue, but there isn't.
> So I suggest just saying that the implementations of `>>' and `<<' have
> been changed to handle negative shift counts and shifts counts greater
> than the word size, and that for efficiency we also provide unchecked
> versions that (like the previous implementations) do not check this.

I agree with this.

> I know that in ANSI C the result of `>>' is implementation defined (not
> undefined) if the left operand is negative.  But that is only because
> ANSI C was supposed to work efficiently even on machines using one's
> complement arithmetic.  All modern machines use two's complement, and
> so, I believe, all C implementations on these machines define `>>' for
> negative left operands in the same way.  Thus there is no good reason for
> Mercury to make `>>' or even `unchecked_right_shift' have undefined
> behaviour in the case where the left hand operand is negative.

Depending on all C implementations on two's complement to define shift
by a negative amount the same way would not be a good idea. On some machines,
the shift amount is handled as unsigned, so what you think is a negative
number will be treated as a large positive number.

> Instead, I would suggest just adding some test cases to the test suite
> to check the behaviour of `>>' and/or `unchecked_left_shift' with
> negative left operands.  These tests will ensure that in the unlikely
> event that we should ever try to port Mercury to a C compiler which
> defines the semantics of `>>' for negative left operations differently,
> we will discover the problem.

However, this is an acceptable workaround, so overall I agree with Fergus's
suggestion.

Zoltan.