-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
util.c: fix _WIN32 port of strptime #3071
Conversation
83ba247
to
efabe01
Compare
32a86c8
to
ec6b308
Compare
This was sent upstream as https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=58041 or? wait for that before merge? |
This was fixed in NetBSD rewriting the loop in a different way; I could port the NetBSD fix to jq instead of using mine. |
Ok, if equivalent fix i think using the netbsd version will be less confusing, thinking if there will be backports in the future etc |
271e10f
to
efa41d0
Compare
The NetBSD code triggers another warning:
|
the joy! 🥳 |
In windows, time_t is a signed 32-bit integer type, so TIME_MAX needs to be declared as INT32_MAX instead of INT64_MAX. Also bump NetBSD's strptime to revision 1.65 from 1.63 to fix undefined behaviour (signed integer overflow) bugs. Related NetBSD problem report: https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=58041 Noticed thanks to a compiler warning in the windows build CI.
In _WIN32 builds, TIME_MAX needs to be INT32_MAX.
Also fix UB overflow, and useless check in NetBSD's
strptime("%s")
:is always true since
time_t
is signed, andTIME_MAX
is its maximum value.And, if it is not optimised out, it causes a signed integer overflow (undefined in standard C) for inputs that start with a sequence of characters between "922337203685477581" and "999999999999999999" (inclusive, 64-bit
time_t
).Also, since the check does not do what it is supposed to do, even if we assume that signed integer overflow is defined like for unsigned integers, on builds where
time_t
isint32_t
, andTIME_MAX
isINT32_MAX
, this will causestrptime("%s")
to accept 99999999999 as a valid timestamp, equivalent to 1410065398 (Sun 7 Sep 04:49:58 UTC 2014
) instead of rejecting it.This works because
floor(log10(UINT32_MAX)) == floor(log10(INT32_MAX))
in 32-bit.Noticed thanks to a compiler warning in the windows build CI.