curl / Mailing Lists / curl-library / Single Mail


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

From: Daniel Stenberg <>
Date: Mon, 16 Apr 2018 16:00:25 +0200 (CEST)

On Fri, 13 Apr 2018, Philip Prindeville wrote:

>> We're still doing C89, remember?
> Is it worth throwing a switch, cutting the shackle, etc. at some point?

I think that's indeed a discussion worth having. An early question will of
course thhen be how we should proceed to take that decision. Whenever we do,
there will be N% of upset users somewhere. How many N is small enough? What
upset level is acceptable? And what's the gain. What's the grand upside we get
by cutting off the far end of the tail?

We can't ask users this question, because the users most in need for support
ancient machines and systems aren't around regularly. It's complicated

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

Why would it *require* 64 bits? Even within 32 bits, or say 31 bits when
signed, we can have 2000 seconds with microsecond accuracy and most times that
curl measures are surely within that time period.

Secondly; even if you would limit the functionality to only work on 64 bit
machines, I don't think you should #ifdef the header file like you've done in

> Unrelated question, why is there CURL_SIZEOF_CURL_OFF_T and

Global symbols *must* be prefixed with curl_ or CURL_. So anything define in
curl/system.h will be named like that.

Symbols that are private to the curl or libcurl build can be named whatever.

We *used* to provide CURL_SIZEOF_CURL_OFF_T in curl/system.h but we don't
anymore, so there's a #define CURL_SIZEOF_CURL_OFF_T SIZEOF_CURL_OFF_T in
lib/curl_setup.h to make the older code remain functional. So internally
they're identical but CURL_SIZEOF_CURL_OFF_T is deprecated.

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

long is 64 bit on your hardware so what's the problem?

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



Received on 2018-04-16