On 26.11.2024 15:39, Teddy Astie wrote:
> Le 26/11/2024 à 14:20, Jan Beulich a écrit :
>>>> Signed-ness of plain char doesn't really matter as long as it's used only
>>>> for
>>>> what really are characters (or strings thereof). And that looks the be
>>>> pretty
>>>> much the case throughout the public headers.
>>> Maybe. Still, as a general principle caller and callee ought to agree on
>>> size,
>>> alignment and sign for every type. I'd rather not make exceptions for that
>>> invariant unless truly well motivated. And in this case it's a case of
>>> requiring trivial non-functional changes.
>> In how far they're non-functional will need to be seen. You also need to keep
>> consumers in mind: They may face sudden type disagreement that compilers may
>> complain about. Yet "stable" for the public headers means not just the ABI
>> itself being stable, but updated headers also being usable as drop-in
>> replacements for older versions.
>
> I don't think we currently enforce stability on all Xen headers
> (especially not those control-domain related).
> For instance
>
> Commit 21e3ef57e0406b6b9a783f721f29df8f91a00f99
> x86: Rename {domctl,sysctl}.cpu_policy.{cpuid,msr}_policy fields
>
> actually modifies the name of some fields in a struct of sysctl.h, so I
> suppose modifying the type of fields with more defined variants is
> acceptable.
Context shifted away from what the subject says, towards doing replacement
on _all_ public headers. For domctl/sysctl and other toolstack-only ones
the transformation would indeed be less problematic (it would be mainly us
who need to adjust the wrapper functions in the libraries).
> One thing remain is that if the user is not careful of this change and
> char is silently replaced by uint8_t, could that break something by
> possibly changing the signed-ness ?
Well, sure, such a risk exists. Much would depend on how the wrapper
functions were adjusted.
Jan
