Re: Backport request (was: [PATCH v2] tools: convert bitfields to unsigned type)

["Roger Pau Monné" <roger.pau@citrix.com>]

On Tue, Jul 04, 2023 at 06:04:36PM +0200, Jan Beulich wrote:
> On 04.07.2023 17:55, Roger Pau Monné wrote:
> > On Tue, Jul 04, 2023 at 05:42:33PM +0200, Jan Beulich wrote:
> >> On 28.06.2023 11:46, Roger Pau Monné wrote:
> >>> On Mon, May 08, 2023 at 04:46:18PM +0000, Olaf Hering wrote:
> >>>> clang complains about the signed type:
> >>>>
> >>>> implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Wsingle-bit-bitfield-constant-conversion]
> >>>>
> >>>> The potential ABI change in libxenvchan is covered by the Xen version based SONAME.
> >>>>
> >>>> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> >>>
> >>> Can we have this one backported to 4.17 at least?
> >>
> >> Hmm, while perhaps simple enough, in principle this wouldn't be a backporting
> >> candidate. May I ask why you consider this relevant?
> > 
> > I have to take this fix in order to build 4.17 with current FreeBSD
> > clang.  I think in the past we have backported changes in order to
> > build with newer gcc versions.
> 
> We did, and this is good enough a justification.
> 
> >> Plus is the mentioned
> >> "potential ABI change" safe to take on a stable branch? There's not going to
> >> be any SONAME change ...
> > 
> > Is there any ABI change in practice? Both fields will still have a 1bit
> > size.
> 
> But what a consumer of the interface reads out of such a field would change
> in case their compiler settings arrange for signed bitfields when signedness
> isn't explicit. We don't dictate, after all, what compiler settings to use
> with our interfaces (which generally is good, but which bites us here).

Hm, I see.  I would argue that sign doesn't matter here, as those are
intended to be booleans, so anything different than 0 would map to
`true`.  But implementation might have hard coded TRUE to -1, and the
change would then break them?

I'm failing to see that, because those implementations would still use
the old struct declarations they have been built with, and hence would
still threat it as signed?

Thanks, Roger.