Robert Haas writes:
>> I'm not sure this fixes it, although I haven't tested. When we take
>> the /* store first fractional byte */ branch, destbitsleft is between
>> 1 and 7 bits greater than srcbitsleft. We then subtract 8 from
>> destbitsleft, and the comment on the next line now asserts that
Woops, forgot to copy the list.
On Sat, Dec 12, 2009 at 2:15 PM, Robert Haas wrote:
> On Sat, Dec 12, 2009 at 2:00 PM, Tom Lane wrote:
>> Roman Kononov writes:
>>> The bitfromint8() and bitfromint4() are hosed. They produce wrong
>>> results when the BIT size is more than 64 and 32 respectively
Roman Kononov writes:
> The bitfromint8() and bitfromint4() are hosed. They produce wrong
> results when the BIT size is more than 64 and 32 respectively, and the
> BIT size is not multiple of 8, and the most significant byte of the
> integer value is not 0x00 or 0xff.
Hm, you're right, it's d
The bitfromint8() and bitfromint4() are hosed. They produce wrong
results when the BIT size is more than 64 and 32 respectively, and the
BIT size is not multiple of 8, and the most significant byte of the
integer value is not 0x00 or 0xff.
For example:
test=# select (11::int4<<23 | 11::int4):
The following bug has been logged online:
Bug reference: 5237
Logged by: Roman Kononov
Email address: kono...@ftml.net
PostgreSQL version: 8.4.1
Operating system: GNU/Linux x86_64
Description:strange int->bit and bit->int conversions
Details:
test=# select (11::int4
