On Mon, Jul 20, 2026 at 02:51:09PM +0200, Morten Brørup wrote: > > From: Bruce Richardson [mailto:[email protected]] > > Sent: Monday, 20 July 2026 14.13 > > > > On Mon, Jul 20, 2026 at 01:46:02PM +0200, Maxime Leroy wrote: > > > The coding style advised against bool in structures, citing space and > > > type-size concerns inherited from the Linux kernel. That does not > > match > > > DPDK practice: bool is already used in over 1400 structure fields > > across > > > the tree, including core APIs such as rte_flow. Drop the note so the > > > style guide reflects actual usage. > > The note is still valid, although massively violated. > Could we paraphrase the note as an advice/recommendation, instead of > completely removing it? > The intention is to make developers consider alternatives when adding a > Boolean field to a structure. > Maybe it could be expanded with a few example alternatives: > uint8_t value, or > uintN_t value:1 (bitfield). > I don't think we want those alternative approaches. If something is a boolean value, then let's just store it as a bool and be done with it. If we store it as an int type then we need comments documenting that it's actually a flag. If it's a bit type, then the field becomes just that little bit more awkward to manage - though still a good choice if the struct is size-sensitive.
Because of this, I'd be in favour of just removing the text and then letting the developer choose the best field type for the job. If bool is a bad choice for a given situation, that should be caught in review. /Bruce
