Some older gcc toolchains don't define these on 32 bit platforms. This
is a problem for pigweed which uses an older gcc toolchain and targets
32 bit.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Unfortunately that won't work for gcc whose limits.h https://gnu.googlesource.com/gcc/+/refs/heads/trunk/gcc/glimits.h doesn't use include_next. The compiler header will be chosen first.
alright, in that case since this is exclusively for internal use then I'm okay with having our own definitions for these constants. I'd prefer to use constexpr variables for this instead of macros, since those provide better type checking.
src/__support/CPP/limits.h | ||
---|---|---|
16 ↗ | (On Diff #547236) | While in almost every case this is safe, I'd still prefer not to assume that long long is 64 bits. Either (sizeof(long long) * 8) - 1 or some other way to calculate the size would be better. |
libc/src/__support/CPP/limits.h | ||
---|---|---|
19 | This constant name in the header is a bit too generic. Maybe you can name it: constexpr size_t LLONG_BIT_WIDTH = sizeof(long long) * 8; and use LLONG_BIT_WIDTH - 1 instead of size_bits below. Or we can add the templates BitWidth<T>::value = sizeof(T) * 8 and MostSignificantBitExponent<T>::value = BitWidth<T>::value - 1 or something like this, as they are actually used in many places. |
This constant name in the header is a bit too generic. Maybe you can name it:
and use LLONG_BIT_WIDTH - 1 instead of size_bits below.
Or we can add the templates BitWidth<T>::value = sizeof(T) * 8 and MostSignificantBitExponent<T>::value = BitWidth<T>::value - 1 or something like this, as they are actually used in many places.