lib517: use LL 64-bit literals & re-enable a test case (time_t)#18032
Closed
vszakats wants to merge 39 commits intocurl:masterfrom
Closed
lib517: use LL 64-bit literals & re-enable a test case (time_t)#18032vszakats wants to merge 39 commits intocurl:masterfrom
LL 64-bit literals & re-enable a test case (time_t)#18032vszakats wants to merge 39 commits intocurl:masterfrom
Conversation
dl-mingw, CM 4.8.1-x86_64 schannel (mingw-w64 3.0):
```
D:/a/curl/curl/tests/libtest/lib517.c: In function 'test_lib517':
D:/a/curl/curl/tests/libtest/lib517.c:147:5: error: this decimal constant is unsigned only in ISO C90 [-Werror]
{"Sun, 06 Nov 2044 08:49:37 GMT", (time_t) 2362034977 },
^
[normally commented:]
D:/a/curl/curl/tests/libtest/lib517.c:150:5: error: this decimal constant is unsigned only in ISO C90 [-Werror]
{"Sun, 06 Nov 1900 08:49:37 GMT", -2182259423 }, /* causes warning on MSVC */
^
```
https://github.com/curl/curl/actions/runs/16540378828/job/46780712313?pr=18010#step:12:32
https://stackoverflow.com/questions/9941261/warning-this-decimal-constant-is-unsigned-only-in-iso-c90
https://gcc.gnu.org/legacy-ml/gcc-bugs/2003-04/msg00082.html
seen with VS2010 - VS2022: ``` C:\a\curl\curl\tests\libtest\lib517.c(150,39): warning C4146: unary minus operator applied to unsigned type, result still unsigned ``` https://github.com/curl/curl/actions/runs/16540722999/job/46781562446?pr=18010#step:11:70 ```c int main(void) { time_t t = -2182259423; return (int)t; ```
``` --pd---e--- OK (503 out of 1779, remaining: 02:32, took 0.298s, duration: 01:00) test 0517...[curl_getdate() testing] libtests.exe returned 44, when expecting 0 517: exit FAILED == Contents of files in the log/6/ dir after test 517 === Start of file commands.log ./libtest/Debug/libtests.exe lib517 nothing > log/6/stdout517 2> log/6/stderr517 === End of file commands.log === Start of file server.cmd Testnum 517 === End of file server.cmd === Start of file stderr517 URL: nothing Test ended with result 44 === End of file stderr517 === Start of file stdout517 WRONGLY Sun, 06 Nov 1900 08:49:37 GMT => 2112707873 (instead of 2112707873) === End of file stdout517 ``` https://github.com/curl/curl/actions/runs/16541254277/job/46782773726?pr=18010#step:13:1092
This reverts commit b64827a.
5.1.0 has these:
```
D:/a/curl/curl/lib/cfilters.c: In function 'Curl_pollset_add_socks':
D:/a/curl/curl/lib/cfilters.c:1073:19: error: array subscript is above array bounds [-Werror=array-bounds]
if(ps->sockets[i] == sock) {
^
D:/a/curl/curl/lib/cfilters.c:1073:19: error: array subscript is above array bounds [-Werror=array-bounds]
if(ps->sockets[i] == sock) {
^
D:/a/curl/curl/lib/cfilters.c:1073:19: error: array subscript is above array bounds [-Werror=array-bounds]
if(ps->sockets[i] == sock) {
^
[...]
D:/a/curl/curl/lib/multi_ev.c: In function 'mev_pollset_diff':
D:/a/curl/curl/lib/multi_ev.c:366:33: error: array subscript is above array bounds [-Werror=array-bounds]
if(s == prev_ps->sockets[j]) {
^
D:/a/curl/curl/lib/multi_ev.c:385:26: error: array subscript is above array bounds [-Werror=array-bounds]
if(s == ps->sockets[j]) {
^
D:/a/curl/curl/lib/multi_ev.c: In function 'Curl_multi_ev_assess_xfer_bset':
D:/a/curl/curl/lib/multi_ev.c:366:33: error: array subscript is above array bounds [-Werror=array-bounds]
if(s == prev_ps->sockets[j]) {
^
D:/a/curl/curl/lib/multi_ev.c:385:26: error: array subscript is above array bounds [-Werror=array-bounds]
if(s == ps->sockets[j]) {
^
```
https://github.com/curl/curl/actions/runs/16541382663/job/46783114823?pr=18010
This reverts commit 9dd4094.
This reverts commit 2a37bc9.
Member
Author
|
The Linux gcc jobs forcing C89 do compile the "problematic" test without any warning. |
6 tasks
Member
Is |
Member
Author
|
Existing code uses edit: also in The use in this PR is guarded for 64-bit Due to the above, I think it's unlikely to cause new problems. There is an alternative way I tried first: It has a slight disadvantage that it |
time_t)
time_t)LL 64-bit literals & re-enable a test case (time_t)
Member
Author
|
Using This warning is explicitly suppressed in curl via It suggests that even though On godbolt, I could find two C compilers that did not support long long, int main(void) {
long long t1 = 2362034977LL;
long long hello1 = 2362034977;
long long hello2 = -2182259423;
(void)t1;
(void)hello1;
(void)hello2;
return 0;
} |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Suffix two 64-bit
time_ttest literals withLLto make them compilewith mingw-w64 x86_64 in C89 (the default) mode. Possibly other old gcc
compilers are affected (e.g. mips gcc 4.9.4, power gcc 15.1.0), but
could not pinpoint the exact rules. This also fixes a compiler warning
and test failure with MSVC, allowing to re-enable a disabled test case.
LLis not C89, but used in the code before this patch, which tellsit's safe to use.
Also display expected / actual timestamp values as
curl_off_tinsteadof
long, making them work with 64-bit timestamps.This was triggered by this issue seen while testing mingw-w64 gcc 4.8.1:
Ref: https://github.com/curl/curl/actions/runs/16540378828/job/46780712313?pr=18010#step:12:32
An alternative way to fix this is to limit these two test cases for C99+ builds.
But, the standard way to detect it misses some compilers like MSVC and
Intel C. The second test (which was disabled before) needs to be excluded
from MSVC permanently due the test failing. Another issue is that non-mingw64
gcc builds seems to compile the problematic test regardless of version and/or
C89. I couldn't figure out the reason. (This made this method skip the first
test on GHA/Linux for openssl jobs with forced C89 mode.)