getinfo: return sizes as curl_off_t

[bagder]

This change introduces new alternatives for the existing six
curl_easy_getinfo() options that return sizes or speeds as doubles. The
new versions are named like the old ones but with an appended '2':

CURLINFO_CONTENT_LENGTH_DOWNLOAD2
CURLINFO_CONTENT_LENGTH_UPLOAD2
CURLINFO_SIZE_DOWNLOAD2
CURLINFO_SIZE_UPLOAD2
CURLINFO_SPEED_DOWNLOAD2
CURLINFO_SPEED_UPLOAD2

[mention-bot]

@bagder, thanks for your PR! By analyzing the history of the files in this pull request, we identified @jay, @captain-caveman2k and @philipc to be potential reviewers.

[jay]

This isn't a firm objection but I think that might be confusing to the user. Though I understand the func func2 pattern I don't think it would be thought of with macros like this, for example CURLINFO_SIZE_DOWNLOAD2 apply to a second download or what. It requires more cognitive processing. CURLINFO_SIZE_DOWNLOAD_AS_CURL_OFF_T
easier to understand? but longer and won't look very good in code. i don't know.. is there some major disadvantage to the user casting the double back to a curl_off_t for example, who's going above that.

[bagder]

I agree completely on the names. I really don't like adding "2" to the names but I failed to come up with a nice naming scheme that doesn't also make the names extremely long... Would appending just _OFF_T be acceptable?

is there some major disadvantage to the user casting the double back to a curl_off_t for example, who's going above that

There isn't any major disadvantage, no, unless you use extremely large files. For me this is more about correctness, for a less surprising choice and for users not having to typecast the value to get it to a sensible type. These values are kept in curl_off_t internally already. (If I could remove the double returning ones I would, but we need to keep them for compatibility.)

[jay]

_OFF_T could imply off_t not curl_off_t and I think could lead to a mistake for that type would be more likely to lead to a mistake than 2.

There isn't any major disadvantage, no, unless you use extremely large files.

Yeah but just how big would those files have to be, unless you're transferring >8 petabytes (I'm basing this on 2^53 as max integer value once it's cast to double).

[bagder]

New version that uses _T as the new suffix instead.

[coveralls]

Coverage decreased (-0.004%) to 73.158% when pulling a2565d0 on bagder/getinfo-return-sizes-off_t into efc83d6 on master.

[bagder]

Intent announced to the list on June 16.