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 basically!

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

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?



 / daniel.haxx.se
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Reply via email to