Ralf Muschall wrote:
> 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
a) The behaviour in for the >> operator in C is undefined when
the number of steps is larger than the number of bits.
b) Haskell does not have a function called primShiftInt so
you can't say that's intended or not intended.
--
-- Lennart
