[fpc-devel] bitwise shift oddity a << b

[Adriaan van Os]

Jonas Maebe wrote:
> Martin Frb wrote:
>> What is supposed to happen if the 2nd argument is negative?
> 
> I would propose to document it as "undefined behaviour", just like C 
> does (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf , 
> section 4.5.7). The reason is that the behaviour can differ depending on 

Section 6.5.7. But in that standard the behaviour is undefined also when "the value of the right 
operand is greater than or equal to the width of the promoted left operand", which I think is a bit 
too simplistic (since, if we start talking about the maximum number of bits that can "legally" be 
shifted, then that number depends on the actual value of the left operand, but on the other hand if 
we accept that bits get lost, then there is no reason to limit the number of bits that can be shifted)

> the cpu, so if you want to guarantee consistent behaviour on all 
> platforms, you can no longer just emit a shift left/right instruction 
> and have to add all kinds of checks.
> 
> Maybe we should support emitting range checks for the right operand 
> though (to give an error if it falls outside the range of shift values 
> whose behaviour is defined).

The right operand of a bitwise shift is a count, a real-world number of bits. A negative number 
doesn' t make sense and must regarded as an error. So yes, emitting range checking is the right 
idea. We should do better in Pascal than in C .....

Regards,

Adriaan van Os