Hello everyone, so, after more tinkering and adjustments, I've arrived at a state I find satisfactory to my tastes.
The current state is in https://github.com/le-jzr/helenos/tree/types (different branch from the old link). I tested build of all architectures, and I'm hoping to merge it into mainline soon. Since it is a fairly substantial change, I'd like everyone who's currently working on HelenOS to give it a look-over and voice any concerns (or lack of concerns). Points of particular interest: - abi/include/_bits directory - _bits/macros.h file - tools/autotool.py (changed generation of common.h to conditionally define missing macros; at this moment, the header is not used anywhere, because it's not needed when building with gcc or clang, but it can be used as a fallback to e.g. support building stuff using pcc) -- jzr On 11 October 2017 at 16:32, Jiří Zárevúcky <[email protected]> wrote: > On 11 October 2017 at 08:27, Jakub Jermář <[email protected]> wrote: >> >>> 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? >> > > One benefit is that it gives you a complete picture of all aspects of > the type. The type and all associated macros, which would normally be > spread over multiple files, are all bundled in one place. Similarly, > by reading the whole macros.h top to bottom, you get a complete > picture of how all integer types are defined and how they relate to > each other. > > More importantly, in some cases it is useful to defer to the compiler. > In the particular case of size_t, the current definition prevents > changing the target triple on ia32, because the type is defined > incompatibly with what the compiler expects it to be. In this case, > macros.h simply checks that __SIZE_TYPE__ is defined by the compiler. > In essense, we need some of the predefined macros from the compiler, > but they don't provide everything we need, so macros.h smooths over > the kinks of a particular compiler and establishes a reliable, > well-defined environment. This emphasises the fact that conceptually, > these types are not defined by the headers, they are defined by the > compiler ABI. The individual headers like <_blop/size_t.h> just > forward the information. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
