Fork us on GitHub Follow us on Facebook Follow us on Twitter

Opened 5 years ago

Closed 5 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 Changed 5 years ago by 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.

comment:2 Changed 5 years ago by 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.

comment:3 Changed 5 years ago by 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.

comment:4 Changed 5 years ago by 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.)

comment:5 Changed 5 years ago by Martin Decky

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

comment:6 Changed 5 years ago by Jiri Svoboda

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