Re: [PATCH v1 5/5] CODING_STYLE: add .clang-format

[Jan Beulich <jbeulich@xxxxxxxx>]

On 01.12.2022 11:47, Julien Grall wrote:
> 
> 
> On 01/12/2022 10:44, Juergen Gross wrote:
>> On 01.12.22 11:12, Julien Grall wrote:
>>>> We might want to add a comment to xs_wire.h like the one in ring.h in 
>>>> order to
>>>> document the requirement of the type definition of uint32_t.
>>>
>>> The problem with this approach is you made more difficult for any 
>>> userspace application to use the headers. So I would argue that the 
>>> Linux copy can remove "stdint.h" if needed.
>>
>> Today there is exactly one public header including stdint.h, and I'd argue
>> that this was a mistake.

I think so, too.

>> xs_wire.h is especially rather uninteresting for any user space application
>> but a Xenstore implementation. All consumers of xs_wire.h are probably
>> either in the Xen tree, or operating system kernels. User space 
>> applications
>> should use libxenstore for accessing the Xenstore, so I don't see an
>> advantage in breaking the usual philosophy of the Xen public headers NOT
>> including external headers like stdint.h.
> 
> I think Edwin example is a pretty good justification for including 
> stdint.h.

I disagree. The intention has always been for consumers to provide the
basic C99 types by whatever suitable means they have. Note that in Xen
we also have no stdint.h.

> If you have a coding style requiring to order header alphabetically, 
> then the developer may not even be able to include stdint.h without any 
> hackery (e.g. introducing a header that will always be before the Xen 
> public headers).

Just to indicate that commonly style requirements may be weaker than
"fully alphabetic" - we don't request full ordering. What we request is
that groups (xen/, asm/, public/) be ordered within any group, but we
do not (afaia) demand ordering across groups (and indeed commonly we
have asm/ after xen/).

Jan