> On Apr 13, 2018, at 3:18 AM, Daniel Stenberg <dan...@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

Reply via email to