> On Apr 13, 2018, at 3:18 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Thu, 12 Apr 2018, Philip Prindeville wrote:
>
>> I was looking at <include/curl/system.h> and it’s a little hairy.
>
> Yes it is, but it works pretty good.
>
>> Can we just do something simple/stupid, like include <stdint.h>
>
> That's a standard header since *C99* so we can't reliably include that without knowing that it exists. We're still doing C89, remember?

Is it worth throwing a switch, cutting the shackle, etc. at some point?

>
>> and if uint64_t is included then we support these timestamps, and if not, then we don’t?
>
> uint64_t is not a standard type in C89, so that takes us back to #ifdefs …

Okay, let me ask the question differently…. We could alias a seconds/microseconds counter as a curl_off_t if the sizeof(curl_off_t) == 8… and not expose the functionality otherwise.

Is that acceptable?

>
>>>> So we might want to express times as uint64_t
>>> For what option(s) would this be used?
>>
>> /* Fill in new entries below here! */
>> CURLINFO_TOTAL_TIME_T = CURLINFO_USECS + 50,
>> CURLINFO_NAMELOOKUP_TIME_T = CURLINFO_USECS + 51,
>> CURLINFO_CONNECT_TIME_T = CURLINFO_USECS + 52,
>> CURLINFO_PRETRANSFER_TIME_T = CURLINFO_USECS + 53,
>> CURLINFO_STARTTRANSFER_TIME_T = CURLINFO_USECS + 54,
>> CURLINFO_REDIRECT_TIME_T = CURLINFO_USECS + 55,
>> CURLINFO_APPCONNECT_TIME_T = CURLINFO_USECS_T + 56,
>
> These *_T time options already return the times as curl_off_t, which is a 64bit type on most systems. Isn't that good enough?

Okay, you lost me. I’m proposing adding the above CURLINFO_*’s.

Currently there’s CURLINFO_TOTAL_TIME which takes a &double.

What’s the homologous interface which returns a curl_off_t? I’m not seeing it.

Looking in lib/getinfo.c I’m not seeing any time-based interrogatories in getinfo_offt() other than CURLINFO_FILETIME_T, using curl_off_t *… as an alias for time_t. But even time_t is limited to seconds resolution.

A uint64_t when representing microseconds wouldn’t wrap until 18446744073709 seconds had passed, or 584574 years, or the year 586,544AD (assuming a 1970 base).

Unrelated question, why is there CURL_SIZEOF_CURL_OFF_T and SIZEOF_CURL_OFF_T? What’s the difference? My config.log is showing:

#define SIZEOF_SIZE_T 8
#define SIZEOF_LONG 8
#define SIZEOF_INT 4
#define SIZEOF_SHORT 2
#define SIZEOF_TIME_T 8
#define SIZEOF_OFF_T 8
#define SIZEOF_CURL_OFF_T 8
#define HAVE_LONGLONG 1
#define CURL_SIZEOF_CURL_SOCKLEN_T 4

But include/curl/curl.h doesn’t seem to have access to SIZEOF_CURL_OFF_T … Is there a way to make something be conditional in <curl/curl.h> on the value of SIZEOF_CURL_OFF_T.

And I’m building on Fedora 27 running on x86_64 hardware, but curl_off_t is being defined as “long”… What did I not do right? Not seeing anything in ./configure that I missed…

Trying to get https://github.com/curl/curl/pull/2495 submission worthy.

>
>>> I think we offer most of those values as 'curl_off_t'
>>
>> I couldn’t figure out if that’s guaranteed to be 64-bits in all cases.
>
> No, as It can't be. There's no general *guaranteed* 64 bit availability in curl code (except some parts that #ifdefs on that fact). But in general that's not a problem. You get it as a 64bit type for all the system on which we can use 64 bits (which in reality is most systems you use in modern life).

What about a struct with an uint32_t upper and lower half as a workaround elsewhere?

Ugly, but…

>
>>>> Is there some easy way to use a callback that gets called immediately after the connect() completes?
>>>
>>> No, we have no such dedicated callback.
>>
>> Could the debug function be overloaded?
>
> Everything is possible as we're talking about code here, but I would first go back and ask: why - what's the benefit here and the use case that you can't just work-around or fulfill with existing functionality. Then, as a secondary follow-up, we could discuss that if we deem this to be a really good idea then how would we implement it.
>
> To me, this idea smells a lot like the old idea to expose the internal state of the multi handle which also has been mentioned from time to time but I've never been persuaded the price is worth the minor benefit to some apps.
>
> --

No, like I mentioned previously, I’m involved in LMAP and we tend to decompose tests into constituent phases, e.g. if I do a 50MB download, it’s not enough to know that it took 8 seconds… It might be the case that the download proper took 2 seconds but name resolution took 6…

-Philip

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-04-14