nathanchance 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). https://github.com/llvm/llvm-project/pull/234780 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
