Opened 7 years ago
Closed 7 years ago
#680 closed defect (fixed)
ABI headers are not self-contained
Reported by: | Jiri Svoboda | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 0.7.1 |
Component: | helenos/unspecified | Version: | mainline |
Keywords: | Cc: | ||
Blocker for: | Depends on: | ||
See also: |
Description
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).
Change History (6)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
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.
comment:3 by , 7 years ago
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.
comment:4 by , 7 years ago
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.)
comment:5 by , 7 years ago
OK, let's postpone the discussion until there is an actual change to the headers.
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.