On Sun, Apr 20, 2008 at 12:27:38PM -0400, Tom Lane wrote: > Sam Mason <[EMAIL PROTECTED]> 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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
