ojhunt wrote: > > > The kernel unconditionally defines `int64_t` as `u64` / `unsigned long > > > long` in `include/linux/types.h` because this will guarantee a 64-bit > > > wide type for both 64-bit and 32-bit platforms. > > > > > > If the only concern is having a 64bit type on 64bit and 32bit systems why > > is `__INT64_TYPE__` not an option? that's a 64bit integer type that is > > predefined by gcc and clang? > > This would require a massive amount of work that I think would be incredibly > hard to sell to the kernel in total. The `s64` / `u64` types would have to > use the `_TYPE__` macros as well because there are places in the kernel where > these types mix with the fixed-width ones. Trying to do that runs amok of the > fact that `int64_t == s64 == long long` / `uint64_t == u64 == unsigned long > long` has been true for the kernel for many many years and there are places > where the types are used interchangeably. That doesn't even get to the fact > that every place where these types are being printed and converting the `%ll` > specifier to `PRI`, which I think would be a non-starter for having to depend > on `inttypes.h` (the kernel uses `-nostdinc` without `-isystem` for the whole > kernel except where needed for intrinsics like mentioned above).
Sigh, I guess the ship sailed on linux (and everyone else) using sensible type names when C decided not to have them :( https://github.com/llvm/llvm-project/pull/234780 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
