Thread: Change definitions of bitmap flags to bit-shifting style
The attached patch changes definitions like
#define FOO 0x01
#define BAR 0x02
to
#define FOO (1 << 0)
#define BAR (1 << 1)
etc.
Both styles are currently in use, but the latter style seems more
readable and easier to update.
This change only addresses bitmaps used in memory (e.g., for parsing or
specific function APIs), where the actual bits don't really matter.
Bits that might go on disk weren't touched. There, defining the bits in
a more concrete way seems better.
Attachment
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> The attached patch changes definitions like
> #define FOO 0x01
> #define BAR 0x02
> to
> #define FOO (1 << 0)
> #define BAR (1 << 1)
> etc.
> Both styles are currently in use, but the latter style seems more
> readable and easier to update.
FWIW, personally I'd vote for doing the exact opposite. When you are
debugging and examining the contents of a bitmask variable, it's easier to
correlate a value like "0x03" with definitions made in the former style.
Or at least I think so; maybe others see it differently.
regards, tom lane
On 2020-Dec-05, Tom Lane wrote: > FWIW, personally I'd vote for doing the exact opposite. When you are > debugging and examining the contents of a bitmask variable, it's easier to > correlate a value like "0x03" with definitions made in the former style. > Or at least I think so; maybe others see it differently. The hexadecimal representation is more natural to me than bit-shifting, so I would prefer to use that style too. But maybe I'm trained to it because of looking at t_infomask symbols constantly.
On Sat, 2020-12-05 at 13:03 -0500, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: > > > The attached patch changes definitions like > > #define FOO 0x01 > > #define BAR 0x02 > > to > > #define FOO (1 << 0) > > #define BAR (1 << 1) > > etc. > > > Both styles are currently in use, but the latter style seems more > > readable and easier to update. > > FWIW, personally I'd vote for doing the exact opposite. When you are > debugging and examining the contents of a bitmask variable, it's easier to > correlate a value like "0x03" with definitions made in the former style. > Or at least I think so; maybe others see it differently. +1 Laurenz Albe
On Sat, Dec 05, 2020 at 10:31:09PM -0300, Alvaro Herrera wrote: > The hexadecimal representation is more natural to me than bit-shifting, > so I would prefer to use that style too. But maybe I'm trained to it > because of looking at t_infomask symbols constantly. If we are going to change all that, hexa style sounds good to me too. Would it be worth an addition to the docs, say in [1] to tell that this is a preferred style? [1]: https://www.postgresql.org/docs/devel/source-conventions.html? -- Michael
Attachment
On Sun, Dec 6, 2020 at 1:25 AM Michael Paquier <michael@paquier.xyz> wrote:
On Sat, Dec 05, 2020 at 10:31:09PM -0300, Alvaro Herrera wrote:
> The hexadecimal representation is more natural to me than bit-shifting,
> so I would prefer to use that style too. But maybe I'm trained to it
> because of looking at t_infomask symbols constantly.
If we are going to change all that, hexa style sounds good to me too.
Would it be worth an addition to the docs, say in [1] to tell that
this is a preferred style?
[1]: https://www.postgresql.org/docs/devel/source-conventions.html?
--
Michael
In my view the bit shifting approach makes it more obvious a single bit is being set, but on the other hand the hex approach makes it easier to compare in debugging.
I’m not really sure which to prefer, though I think I would have leaned slightly towards the former.
James
On 12/6/20 11:44 AM, James Coleman wrote: > On Sun, Dec 6, 2020 at 1:25 AM Michael Paquier <michael@paquier.xyz > <mailto:michael@paquier.xyz>> wrote: > > On Sat, Dec 05, 2020 at 10:31:09PM -0300, Alvaro Herrera wrote: > > The hexadecimal representation is more natural to me than > bit-shifting, > > so I would prefer to use that style too. But maybe I'm trained > to it > > because of looking at t_infomask symbols constantly. > > If we are going to change all that, hexa style sounds good to me too. > Would it be worth an addition to the docs, say in [1] to tell that > this is a preferred style? > > [1]: https://www.postgresql.org/docs/devel/source-conventions.html > <https://www.postgresql.org/docs/devel/source-conventions.html>? > -- > Michael > > > > In my view the bit shifting approach makes it more obvious a single > bit is being set, but on the other hand the hex approach makes it > easier to compare in debugging. > > I’m not really sure which to prefer, though I think I would have > leaned slightly towards the former. > > Perhaps we should put one style or the other in a comment. I take Tom's point, but after the number of bits shifted gets above some number I have trouble remembering which bit it is, and while of course I can work it out, it can be a very minor nuisance. cheers andrew