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:


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 Martin Decky, 7 years ago

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.

comment:2 by Jiri Svoboda, 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 Martin Decky, 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 Jiri Svoboda, 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 Martin Decky, 7 years ago

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

comment:6 by Jiri Svoboda, 7 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.