> On Apr 13, 2018, at 3:18 AM, Daniel Stenberg <[email protected]> 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
