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
