And again a reply from Mathias. Werner
====================================================================== > > > After the shift, the upper half is undefined. > > > > This is wrong. Undefined means undefined in all halves. The wording in the C standard (6.5.7.5) allows this interpretation, but I think it is just poor wording. Bit manipulation with masking, shifting and ORing, as commonly done, usually just works with signed integers as with unsigned integers. It is not recommended to do this with signed integers, but if it wouldn't behave reasonably, a lot of code would break. To look from the machine POV: There are logical and arithmetical shift instructions. The logical ones to the right thing for unsigned numbers, the arithmetical for signed ones. If shifting to the left, both are identical. If shifting right, the difference is whether the new bits shifted in are filled with zero or a copy of the previously leftmost bit. I think the intention for the C standard to allow "implementation defined" behaviour is to allow use of the logical shift machine instruction in cases where the CPU doesn't implement the arithmetical one. Just had a look into a (german) textbook about C. It says that shift operators work for both signed and unsigned numbers in both directions, but the compiler _may_ use arithmetical shifts for signed numbers. This both would mean that bits which are present before and after the shift are not modified. (If you know an implementation where this doesn't hold, please tell me and I'll never shift a signed number again.)
#include <stdio.h> int main() { int f, r1, r2, r3; f = -(1 << 16); r1 = (int)((unsigned int)(f) >> 16); r2 = (int)(short)((f) >> 16); r3 = (int)(short)((unsigned int)(f) >> 16); printf("0x%08x, %d %d %d\n", f, r1, r2, r3); return 0; }
_______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel