include/api/$ARCH/bits/alltypes.h.sh and musl upgrade

[Waldek Kozaczuk]

Can anyone explain the motivation behind this script and how the generated alltypes.h is intended to be used?

I am a little concerned this file might need to be updated as we upgrade musl.

Waldek

[Nadav Har'El]

On Mon, Aug 10, 2020 at 5:21 PM Waldek Kozaczuk <jwkoz...@gmail.com> wrote:

Can anyone explain the motivation behind this script and how the generated alltypes.h is intended to be used?

I can try. I think we took this idea from Musl.

The C library has type definitions in a lot of different header files. For example ssize_t may be in one header file, time_t in another header file, iovec in a third header file, etc.

The problem that "alltypes.h" tries to solve is that we may need to use (because Linux and/or glibc used) slightly different definitions for many of these definitions for different architectures. So instead of filling all the different header files with various architecture-dependent #ifdefs, the idea is to put all these definitions in a single header file, alltypes.h - and have a different alltypes.h for the different architectures - without needing to touch all the other header files.

This gets complicated by the fact that if, say <time.h> included alltypes.h and it also defined pid_t - for example - users can get surprised when they include <time.h> and get definitions the standard doesn't say they should get from time.h. Maybe a user has their own pid_t defined, and didn't think this was a problem because they only included time.h?

This is why alltypes.h only defines pid_t, for example, if __NEED_pid_t is defined. The header file which should define pid_t needs to defined __NEED_pid_t and then include alltypes.h.

The reason why we have this alltypes.h.sh instead of just alltypes.h is to avoid the ugliness of all the #ifdef __NEED_... all over - the script generates them and the result is build/release.x64/gen/include/bits/alltypes.h.

I am a little concerned this file might need to be updated as we upgrade musl.

It might, but then again, these are very basic type definitions that haven't changed in the C standard in many years, so it is unlikely to have changed much.

Take a look at Musl's alltypes.h or alltypes.h.in or whatever they call it, and check what they changed since 2014 - or what we changed from them.