Re: BUG #16403: set_bit function does not have expected effect

I see, so the get/set_bit functions act on bits within individual bytes,
not as a bit stream. Some other languages will act directly on the bits,
rather than iterating over bytes.

A good example of this is in pure C when setting a bit, it is easy to do
programmatically with shifting. This is how I've performed these operations
in the past, specifically when looping over bits.

Eg.
unsigned int x = 13;
unsigned int i = 0;
i |= 1 << x;

This will set the bit in the bytes relative to the right-most position. In
this case, it would return an integer with a value of 32, having bytes with
the hex representation 0x00002000 (when using printf, MSB).

Now that I understand the implementation reasoning, I also understand that
this will probably not change. If there are some bit functions implemented
with the BYTEA type similar to the C above, however, I would definitely
expect it to perform the same way.

On Thu, Apr 30, 2020, 07:57 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Francisco Olarte <folarte(at)peoplecall(dot)com> writes:
> > On Thu, Apr 30, 2020 at 9:47 AM PG Bug reporting form
> > <noreply(at)postgresql(dot)org> wrote:
> >> set_bit function changes the right-most bit of the byte, but with
> >> little-endian byte order. This is confusing to any use case where
> setting a
> >> bit in a BYTEA in a specific position. To iterate through the bits
> within
> >> the BYTEA, one must have nested loops which set bits within byte
> boundaries.
>
> > I think this is a display expectations issue, when using addresses it
> > seems it is changing the least significant bit in the first byte and
> > the second byte ( in C-speak it is setting bit n%8 byte n/8 ),
>
> Yeah, the documentation is quite clear about this:
>
> Functions get_byte and set_byte number the first byte of a binary
> string as byte 0. Functions get_bit and set_bit number bits from the
> right within each byte; for example bit 0 is the least significant bit
> of the first byte, and bit 15 is the most significant bit of the
> second byte.
>
> so we're not likely to change it.
>
> You might consider using type "bit" instead of bytea, since the bit
> display order is more closely tied to how set_bit() numbers the bits.
>
> Another option is to write your own functions that number the bits
> however you want.
>
> regards, tom lane
>