curl / Mailing Lists / curl-library / Single Mail

curl-library

Re: Embedded platforms (without FPU's), etc.

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Fri, 13 Apr 2018 11:18:31 +0200 (CEST)

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?

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

>>> 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?

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

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

-- 
  / daniel.haxx.se

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