-
-
Notifications
You must be signed in to change notification settings - Fork 346
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make time_t
size check message more helpful
#2769
Conversation
time_t
size check message more helpfultime_t
size check message more helpful
@slaff Are you OK with making this a hard assert? There may be a way to generate a deprecation message or warning. There's also the minimum GCC version check in the build which is currently set to 8; can't really change that yet though because of Windows and IDF 4.x. |
@@ -18,7 +18,7 @@ | |||
static_assert(sizeof(time_t) != 8, "Great! Now supports 64-bit - please update code"); | |||
#warning "**Y2038** time_t is only 32-bits in this build configuration" | |||
#else |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If GCC v10 is ok then wouldn't it be better to change this line
from
#else
to
#elif defined(__GNUC__) && __GNUC__ < 10
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps... but as this is technically a glibc issue the more correct way would be to check __USE_TIME_BITS64
- see https://lwn.net/Articles/664800/.
@mikee47 I would prefer a warning. |
API Design In order to avoid duplicating APIs for 32-bit and 64-bit time, glibc will provide either one but not both for a given application; the application code will have to choose between 32-bit or 64-bit time support, and the same set of symbols (e.g. time_t or clock_gettime) will be provided in both cases. The following is proposed:
This allows user code to check, by verifying whether __USE_TIME_BITS64 is defined once glibc headers are #included, that they are using a glibc which actually supports 64-bit time (or claims to).
|
Further to #2758 host builds should generally match code run on hardware. As mentioned this is not straightforward for Windows, but for Linux we should expect 64-bits as the default.
GCC 10+ can make use of
_TIME_BITS
to ensure we get this behaviour. More specifically, this is a feature ofglibc
shipped with those versions.For earlier versions, even though the compiler is 64-bit we are building in 32-bit mode and
time_t
stays stuck in 32-bits. There are various discussions about this but the short answer is that prior to GCC 10 (libc 4) 32-bit applications get 32-bittime_t
.Instead of generating a
static_assert
(which stops compilation) we get a compiler warning - this still requires building in STRICT mode.