On Sat, Apr 19, 2008 at 11:26:57AM -0400, Tom Lane wrote:
> Roman Kononov <[EMAIL PROTECTED]> writes:
> > The below test cases show the obvious inconsistency between different
> > integer types.
>
> [ shrug... ] The << and >> operators just expose the behavior of the
> local C compiler's shift operators, and it's clearly stated in the C
> spec that shifting by more than the word width produces unspecified
> results.
I thought that getting the correct answer was more important than
getting the "wrong" answer quickly. The current code also introduces
its own set of strangeness in the 16 bit case on my x86_64 box. It does
something closer to:
int16 shl (int val, int n) {
n %= 32;
return n < 16 ? val << n : 0;
}
This is exactly what the code says, it's just the resulting semantics
aren't very nice for the user.
Wouldn't it be easy to put some code like this in:
if (arg2 < 16)
return PG_RETURN_INT16(arg1 << arg2);
return PG_RETURN_INT16(0);
People would have one less platform specific weirdo to worry about.
As an aside, I thought it would be interesting to see what MySQL did and
it seems to check for and handle this case--albeit only the 64bit case,
but as far as I can tell it only really knows about "long long" ints.
Sam
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
