Re: [PATCH v3 2/3] docs/devel/style: add a section about bitfield, and disallow them for packed structures

[Pierrick Bouvier]

On 12/10/24 02:10, Philippe Mathieu-Daudé wrote:
> On 10/12/24 08:52, Thomas Huth wrote:
> > On 09/12/2024 21.33, Philippe Mathieu-Daudé wrote:
> > > On 28/11/24 21:15, Pierrick Bouvier wrote:
> > > > Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
> > ...
> > > > +For this reason, we disallow usage of bitfields in packed structures
> > > > and in any
> > > > +structures which are supposed to exactly match a specific layout in
> > > > guest
> > > > +memory. Some existing code may use it, and we carefully ensured the
> > > > layout was
> > > > +the one expected.
> > > > +
> > > > +We also suggest avoiding bitfields even in structures where the exact
> > > > +layout does not matter, unless you can show that they provide a
> > > > significant
> > > > +memory usage or usability benefit.
> > >
> > > I don't think we should mention "significant memory usage benefit".
> >
> > Why not? That's the point of bitfields, isn't it? Or do you mean it's
> > included in "usability benefit" already?
>
> To not generate a reactance effect :) Developers trying to optimize
> memory usage via bit field uses is extremely rare (at least in the
> QEMU community).
>
> Anyhow, I don't object to this patch as is.

I asked initially if we should simply advise against using bitfields, 
but it was not clearly answered if we want to do this or not.

From your answers, it seems that people do not have a bias towards 
using bitfields for memory usage optimizations, so maybe we should 
simply discourage using them at all.
The only case I think of would be a specific struct format exchanged 
with the outside world, but most of the experienced developers know that 
using bitfields in "public" formats is a poor practice.

From all that,
What should we say in the doc then?