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
