Today I saw a strange behavior of primShiftInt in hugs98
(and all other functions which are implemented using the
operators ">> or "<<").
The effect is that an expression like "x >> y" in C behaves
as if it were x >> (y & 0x001F).
E.g. 64 >> 68 gives 4 instead of 0.
I tried this with different versions of gcc and with some old
Borland cc, so it seems to be a widespread problem.
It is unknown whether this is a common bug in the ccs
or a "feature" of the C standard, bit I think that a high
level language should not inherit it.
By defining a few functions like
unsigned int unsined_shr(unsigned int data, int shift_by);
and replacing the ocurrences of ">>","<<" in the file
builtin.c in hugs98 I got a hugs that behaves as expected.
The affected definitions are Int2Int, IntInt2Bool,
primShiftInt, Int2Word, WordInt2Bool, primShiftWord.
GHC 2.something is affected as well (and probably many
other versions and implementations).
Does anybody know whether this is
(1) the intended behavior of both C and haskell
(2) a design decision in C which has been forgotten
to undo in the Hugs (etc.) sources
(3) an unknown bug in many C compilers?
Ralf
