I'm wondering what the correct right-hand operand is for C/C++ bit-shift operators.
At time of writing, the built-in arithmetic types are all less than 256 bits, so a single byte would be sufficient. Furthermore, x86 shift-instructions use imm8. Together this suggests the right-hand operand should be an unsigned char and use of a different type here will require type-conversion.
Is there a "most correct" type to use here? I know the standard is strangely lenient about other aspects of bit-shifting so maybe this is another case of the same?
Any integer type can be used as the right operand of a bitwise shift, so long as the value is at least 0 and less than the bit length of the left operand.
This is spelled out in section 6.5.7 p2 and p3 of the C standard regarding Bitwise Shift Operators:
2 Each of the operands shall have integer type
3 The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand. If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined.
So while the range of an unsigned char should be sufficient to hold any valid value, the right operand will be promoted to int anyway.
C tends to want to do everything as at least int, so it would be very surprising if the RHS of << and >> were to be specified as unsigned short or unsigned char.
It's hard to imagine why a programmer would ever use long (or, god help us, long long) there, but I just tried this code:
int main()
{
int x = 16;
long int y = 2;
int z1 = x << y;
int z2 = x >> y;
printf("%d %d\n", z1, z2);
long long int y2 = 2;
z1 = x << y2;
z2 = x >> y2;
printf("%d %d\n", z1, z2);
}
I compiled it under two compilers, and neither gave any warnings, and both programs printed 64 4. (Not a conclusive test, but suggestive.)