> From: Bruce Richardson [mailto:[email protected]] > Sent: Monday, 20 July 2026 14.58 > > 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
OK, I'll buy that. Acked-by: Morten Brørup <[email protected]>
