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

[Julien Grall <julien@xxxxxxx>]

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...
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).
> > 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.
Cheers,

--
Julien Grall