lib: prefer var = time(NULL) over time(&var)
#13815
Conversation
Following up on previous occurrences showing up as gcc warnings, replace the remaining few `time(&var)` calls with `= time(NULL)`, though these aren't specifically causing compiler warnings. All of these are in the TFTP client code (`lib/tftp.c`), except one which is in a debug branch in `lib/http_aws_sigv4`. What's unexplainable is that this patch seems to stabilize the TFTP tests regularly hanging or going into an infinite loop on GHA windows workflows with MSYS2, mingw-w64 and MSVC (Cygwin is unaffected): curl#13599 (comment) I figure it's something worth trying even if it turns out to be a dead end. `time()` docs: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/time-time32-time64 https://manpages.debian.org/bookworm/manpages-dev/time.2.en.html Follow-up to 58ca0a2 curl#13800 Follow-up to d0728c9 curl#13643 Closes #xxxxx
|
Okay, so got hung again right away this time; hard to tell where: |
|
That's truly weird. I wonder if this is a 32/64 bit issue, the msdn time doc says it's supposed to be 64 bit in most cases, and so maybe the reason for the weirdness is time(&foo) is either the function is expecting a 32-bit and the variable is 64 bit or the other way around, and it's writing outside its memory or half the memory isn't written? try using a 64-bit variable explicitly, like edit: oops I forgot about the integer promotion (now < 0xFFFFFFFFUL); so I modified the assertion to cast to 64 bit unsigned edit2: added another assert to see if it's Dan's issue |
|
Truly weird is also a good description of the possibly related TFTP timeout issues I found in #12040. The problem there appeared to be a simple |
|
I could not spot any issues with It'd probably still be a good PR to merge (without re-enabling TFTP tests) just to do these calls the same way across the codebase. The assigment style can also avoid the As a next step maybe it'd be useful to check for a -1 value returned, as Jay suggested. |
|
Another idea is to replace remaining direct edit: modules using @jay: Do you vote to re-enable TFTP tests with this patch, or leave them disabled? We can always disable them again in a separate PR – or try other fixes. |
|
Actually I would leave them disabled because they don't seem to work properly for mingw AFAICS, and based on what you've said and no reports other than us I don't think it's a curl bug |
Curl_now and time are not synonymous, so that would have to be approached very carefully and I don't know if it's worth the work |
I reviewed the time calls in tftp and they are all based around recording the receive timestamp so they could easily be changed to Curl_now edit: Curl_now would be better because it seems for many operating systems the value only increments based on a fixed point in comparison to |
|
Curl_now will use a monotonic time source if available so timeouts won't break when certain clock updates happen.
|
|
OK, let's leave TFTP tests disabled. It still leaves some hangs to deal with, but it removes TFTP as a culprit. |
Following up on previous occurrences showing up as gcc warnings, replace
the remaining
time(&var)calls withvar = time(NULL), though thesearen't specifically causing compiler warnings. These are in the TFTP
client code (
lib/tftp.c), except one which is in a debug branch inlib/http_aws_sigv4.c.What's unexplainable is that this patch seems to mitigate TFTP tests
often hanging or going into an infinite loop on GHA windows workflows
with MSYS2, mingw-w64 and MSVC (Cygwin is unaffected):
#13599 (comment)
TFTP hangs did not entirely disappear though, so could be unrelated.
time()docs:https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/time-time32-time64
https://manpages.debian.org/bookworm/manpages-dev/time.2.en.html
Follow-up to 58ca0a2 #13800
Follow-up to d0728c9 #13643
Closes #13815
More test runs here: vszakats#1