Re: Inconsistent shift operator

On Sun, Apr 20, 2008 at 12:27:38PM -0400, Tom Lane wrote:
> Sam Mason <sam(at)samason(dot)me(dot)uk> writes:
> > 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);
>
> This is a straw man. It covers *one* of the behaviors left undefined
> by the C standard. I quote from C99:

[...]

wow, I never realised how little semantics C actually defines. I'm a
fan of formally defined semantics and the above just seems like a big
cop-out. The case of E1 being negative seems completely implementation
defined!

> We are shifting signed types so we are exposed to every one of these
> unspecified behaviors. In particular, since we don't know whether the
> behavior of >> will be zero-fill or sign-fill, it's not going to be
> exactly trivial to make a consistent extension of it to shift values
> greater than the word width.

About the only reasonable thing I can think of that would remain within
C's spec (at least with respect of shifting) would be to always treat
E1 as an unsigned value. This would allow it to be used consistently
with the other bit-wise operators, but would cause any non-bitwise
interpretation of the result to become implementation defined. Not very
nice.

> By the time you get done replicating all this for the int2, int4,
> and int8 shift operators, it's not looking like such a small patch
> anymore. And I still find the premise entirely unconvincing.

After an afternoon of getting utterly bogged down looking into what
other languages do and getting very distracted with ring theory I'm
tempted to reluctantly agree. Maybe the warning about floats could be
extended to cover the shift operators as well. Maybe:

The bit shift operators only return consistent results when both the
RHS is within the bit-size of the arguments' data type and the LHS is
positive, in all other cases the behaviour is platform specific.

I think that's technically correct, but seems to come across as very
pessimistic.

> Maybe the user *wants* to see the local behavior of shift, whatever
> it might be. It's certainly not impossible that we'd break applications
> that worked fine before (at least on the hardware they were being
> used on).

Yes. It always surprises me how hard getting formal semantics into an
existing language seems to be.

Sam