tool_operate: fix type-limits compiler warning #1378
Conversation
@MarcelRaad, thanks for your PR! By analyzing the history of the files in this pull request, we identified @yangtse, @bagder and @captain-caveman2k to be potential reviewers. |
Ah, seems like GitHub always shows the diff with "compare whitespace changes" - the actual changes of the second commit are best visible with "ignore whitespace changes" as the indentation was changed. |
Oh right, this made me realize |
saving time offset and since it's GMT that is bad behavior. When we have | ||
access to a 64-bit type we can bypass utime and set the times directly. */ | ||
#if defined(WIN32) && (CURL_SIZEOF_CURL_OFF_T >= 8) | ||
#if (CURL_SIZEOF_LONG >= 8) |
jay
Apr 2, 2017
Member
We can't have mixed declarations so HANDLE hfile
would have to be declared before this line. also for all cases we expect filetime to be >= 0, and while I see the caller is checking that it is also appropriate to check in this function at the beginning if(filetime < 0) return
We can't have mixed declarations so HANDLE hfile
would have to be declared before this line. also for all cases we expect filetime to be >= 0, and while I see the caller is checking that it is also appropriate to check in this function at the beginning if(filetime < 0) return
MarcelRaad
Apr 3, 2017
Author
Member
Thanks, good catch! Fixed.
I had tried to configure with -ansi -pedantic
, but got some compile errors. Maybe I should look into that.
Thanks, good catch! Fixed.
I had tried to configure with -ansi -pedantic
, but got some compile errors. Maybe I should look into that.
MarcelRaad
Apr 3, 2017
Author
Member
I also moved the if(filetime >= 0)
into the function. (I didn't do the if(filetime < 0) return
because then the HANDLE
declaration would again be not the first statement in the block.)
I also moved the if(filetime >= 0)
into the function. (I didn't do the if(filetime < 0) return
because then the HANDLE
declaration would again be not the first statement in the block.)
MinGW complains: tool_operate.c:197:15: error: comparison is always true due to limited range of data type [-Werror=type-limits] Fix this by only doing the comparison if 'long' is large enough to hold the constant it is compared with. Closes curl#1378
MinGW complains: tool_operate.c:197:15: error: comparison is always true due to limited range of data type [-Werror=type-limits] Fix this by only doing the comparison if 'long' is large enough to hold the constant it is compared with. Closes curl#1378
} | ||
#endif | ||
} | ||
setfiletime(filetime, outs.filename, config->global->errors); |
jay
Apr 4, 2017
Member
Please put back the filetime >= 0 check here, having the check in both places is appropriate I think. Otherwise this looks fine. Regarding your question about the commit messages, both should have a blank line followed by a reference to this issue. So you can do that with a Ref: xxx line or a Closes xxx line, or if you were responding to someone else's report a Bug: xxx line followed by a Reported-by: xxx line, etc. The important part is there is always a link back to the issue(s) so nobody has to hunt it down in the future if they need more info on it.
Please put back the filetime >= 0 check here, having the check in both places is appropriate I think. Otherwise this looks fine. Regarding your question about the commit messages, both should have a blank line followed by a reference to this issue. So you can do that with a Ref: xxx line or a Closes xxx line, or if you were responding to someone else's report a Bug: xxx line followed by a Reported-by: xxx line, etc. The important part is there is always a link back to the issue(s) so nobody has to hunt it down in the future if they need more info on it.
MarcelRaad
Apr 4, 2017
•
Author
Member
Thanks a lot! I've put back the check at the call site, amended the commit messages with the Ref:/Closes, moved the if(filetime >= 0)
to the first commit, and rebased on current master.
Thanks a lot! I've put back the check at the call site, amended the commit messages with the Ref:/Closes, moved the if(filetime >= 0)
to the first commit, and rebased on current master.
MinGW complains: tool_operate.c:197:15: error: comparison is always true due to limited range of data type [-Werror=type-limits] Fix this by only doing the comparison if 'long' is large enough to hold the constant it is compared with. Closes curl#1378
MinGW complains: tool_operate.c:197:15: error: comparison is always true due to limited range of data type [-Werror=type-limits] Fix this by only doing the comparison if 'long' is large enough to hold the constant it is compared with. Closes #1378
There's a "type-limits" warning with MinGW in tool_operate.c as a variable of type
long
is checked to be smaller than a 64-bit constant, which is always true for 32-bitlong
. Fixed this by doing the comparison only iflong
is at least 64 bits.There are two commits: the first one only moves a part of the very long
operate_do
function to a new function and the second one is the actual warning fix. So the "Closes" should be in the commit message for the second commit, right?(I'm currently trying to get the autobuilds page a little less red and started with the warnings section.)