ABI headers are not self-contained

[Jiri Svoboda]

Quite a few headers under abi/ use uintN_t types without including common.h, thus not being self contained. (You need to include stdint.h or similar before including them).

[Martin Decky]

This is actually by design. The headers in abi/ are not intended to be used by end-applications, they serve only as a internal glue code between the kernel and uspace run-time library. Thus they don't have to be self-contained.

I suggest closing this ticket as not-a-defect.

[Jiri Svoboda]

That's not very neat design, because it means that in the files including these headers the includes need to be in a particular order, which is something unexpected. For any list of includes at the beginning of any source file it should be possible to reorder them in any way (e.g. alphabetically) - something I have in the longer term plan.

I am planning to fix this in the same way as I did with abi/fourcc.h. I'm just making a note so I don't forget.

[Martin Decky]

I understand the concern of not relying on the order of included headers in end-user code. But much less so in internal frameworks that are not supposed to be directly used by end-user developers and where it it fine to define some explicit logical dependencies between categories of header files. This should (a) allow the abi/ headers to be minimal, and (b) avoid enforcing the names and locations of the non-ABI headers to be exactly the same in all possible environments where the ABI headers are used.

[Jiri Svoboda]

Good point about various environments (e.g. if you wanted to use the same header inside HelenOS). That should be easy to rectify. Just instead of incuding something like "../../../common.h" we can include <stdint.h> to get the uintN_t types. That should work in any sane environment (as it's mandated in C standard freestanding env.)

[Martin Decky]

OK, let's postpone the discussion until there is an actual change to the headers.

[Jiri Svoboda]

changeset:mainline,2651