Hi Jiri, On 10/11/2017 04:52 AM, Jiří Zárevúcky wrote: > Instead, I propose the following: > > In the abi/include directory, shared between kernel and uspace, there > shall be a directory of "building block" headers (in my current > implementation, this directory is named "_bits", but this is subject > to bikeshedding). These headers are private and are only supposed to > be included by other headers that expose the API. Each of these > building blocks defines a particular subset of the basic types, at > arbitrary granularity. E.g. there may be <_bits/size_t.h> that defines > just size_t, and <_bits/stdint.h> that defines some or all of > <stdint.h> types.
I like this. > However, the building block headers don't contain the actual > definition of those types and constants, they simply refer to > preestablished macros with reserved names, such as __SIZE_TYPE__. > These macros are established all in one place, in <_bits/macros.h>, > which is where all the real magic happens. macros.h expects a small > subset of predefined macros (which are deliberately picked to be a > subset of predefined macros provided by both GCC and clang, but can > also independently be provided by autotool.py), and derives all the > rest of the information necessary to provide a complete, > self-consistent library. So why is this better than, say, defining size_t directly in _but/size_t.h? Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
