tool_operate: fix type-limits compiler warning

[MarcelRaad]

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-bit long. Fixed this by doing the comparison only if long 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.)

[mention-bot]

@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.

[MarcelRaad]

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.

[bagder]

Oh right, this made me realize CURLINFO_FILETIME has a Y2038 problem even on 64bit windows since the long it returns is 32 bit there, while all other 64bit architectures have 64bit longs...

[jay]

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]

Thanks, good catch! Fixed.
I had tried to configure with -ansi -pedantic, but got some compile errors. Maybe I should look into that.

[MarcelRaad]

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.)

[jay]

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]

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.