Re: Inconsistent shift operator

From: Sam Mason <sam(at)samason(dot)me(dot)uk>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Inconsistent shift operator
Date: 2008-04-20 13:38:42
Message-ID: 20080420133842.GN6870@frubble.xen.chris-lamb.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sat, Apr 19, 2008 at 11:26:57AM -0400, Tom Lane wrote:
> Roman Kononov <kononov(at)dls(dot)net> 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Eisentraut 2008-04-20 15:31:51 Re: BUG #4115: PostgreSQL ISO format is not really ISO
Previous Message Sushil 2008-04-20 12:33:11 executing SELECT xmlelement(name foo); causes "server closed the connection unexpectedly" Error