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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 01.12.2022 12:35, Julien Grall wrote:
> On 01/12/2022 11:30, Jan Beulich wrote:
>> 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.
> 
> I really dislike when I have to find the dependency of an header. This 
> is really a waste of time...

I can see your point, but for Xen's public headers it has always been
that way. Plus, as said, adding (unguarded) #include <stdint.h> would
even break the building of Xen itself.

> If other disagree with that, then the strict minimum would be for this 
> dependency to be recorded if it hasn't been done (I couldn't find anywhere).

It is kind of recorded in xen/include/Makefile, with the three
"-include stdint.h" that are used there (of which one probably really
ought to be -include cstdint). But I agree this can't really count as
documentation.

>>> 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/).
> Right, but that's **our** coding style. You don't know what's going to 
> be the coding style for other project.

Sure, hence me having said "may be" in my reply.

Jan