2008-08-23 19:34:42 +08:00
|
|
|
|
|
|
|
|
curl_off_t explained
|
|
|
|
|
====================
|
|
|
|
|
|
|
|
|
|
curl_off_t is a data type provided by the external libcurl include headers. It
|
|
|
|
|
is the type meant to be used for the curl_easy_setopt() options that end with
|
|
|
|
|
LARGE. The type is 64bit large on most modern platforms.
|
|
|
|
|
|
|
|
|
|
Transition from < 7.19.0 to >= 7.19.0
|
|
|
|
|
-------------------------------------
|
|
|
|
|
|
2008-08-26 21:35:06 +08:00
|
|
|
Applications that used libcurl before 7.19.0 that are rebuilt with a libcurl
|
2008-08-23 19:34:42 +08:00
|
|
|
that is 7.19.0 or later may or may not have to worry about anything of
|
|
|
|
|
this. We have made a significant effort to make the transition really seamless
|
2008-08-27 14:10:47 +08:00
|
|
|
and transparent.
|
2008-08-23 19:34:42 +08:00
|
|
|
|
|
|
|
|
You have have to take notice if you are in one of the following situations:
|
|
|
|
|
|
|
|
|
|
o Your app is using or will after the transition use a libcurl that is built
|
|
|
|
|
with LFS (large file support) disabled even though your system otherwise
|
|
|
|
|
supports it.
|
|
|
|
|
|
|
|
|
|
o Your app is using or will after the transition use a libcurl that doesn't
|
|
|
|
|
support LFS at all, but your system and compiler support 64bit data types.
|
|
|
|
|
|
|
|
|
|
In both these cases, the curl_off_t type will now (after the transition) be
|
2008-08-26 21:35:06 +08:00
|
|
|
64bit where it previously was 32bit. This will cause a binary incompatibility
|
2008-08-23 19:34:42 +08:00
|
|
|
that you MAY need to deal with.
|
|
|
|
|
|
2008-08-26 20:57:29 +08:00
|
|
|
Benefits
|
|
|
|
|
--------
|
|
|
|
|
|
|
|
|
|
This new way has several benefits:
|
|
|
|
|
|
|
|
|
|
o Platforms without LFS support can still use libcurl to do >32 bit file
|
2008-08-27 14:10:47 +08:00
|
|
|
transfers and range operations etc as long as they have >32 bit data-types
|
2008-08-26 20:57:29 +08:00
|
|
|
supported.
|
|
|
|
|
|
|
|
|
|
o Applications will no longer easily build with the curl_off_t size
|
|
|
|
|
mismatched, which has been a very frequent (and annoying) problem with
|
|
|
|
|
libcurl <= 7.18.2
|
|
|
|
|
|
2008-08-27 14:10:47 +08:00
|
|
|
Historically
|
|
|
|
|
------------
|
2008-08-23 19:34:42 +08:00
|
|
|
|
|
|
|
|
Previously, before 7.19.0, the curl_off_t type would be rather strongly
|
|
|
|
|
connected to the size of the system off_t type, where currently curl_off_t is
|
|
|
|
|
independent of that.
|
|
|
|
|
|
|
|
|
|
The strong connection to off_t made it troublesome for application authors
|
|
|
|
|
since when they did mistakes, they could get curl_off_t type of different
|
|
|
|
|
sizes in the app vs libcurl, and that caused strange effects that were hard to
|
|
|
|
|
track and detect by users of libcurl.
|
2008-08-23 19:37:42 +08:00
|
|
|
|
|
|
|
|
SONAME
|
|
|
|
|
------
|
|
|
|
|
|
2008-08-25 05:26:42 +08:00
|
|
|
We opted to not bump the soname for the library unconditionally, simply
|
|
|
|
|
because soname bumping is causing a lot of grief and moaning all over the
|
|
|
|
|
community so we try to keep that at minimum. Also, our selected design path
|
|
|
|
|
should be 100% backwards compatible for the vast majority of all libcurl
|
|
|
|
|
users.
|
|
|
|
|
|
|
|
|
|
Enforce SONAME bump
|
|
|
|
|
-------------------
|
|
|
|
|
|
|
|
|
|
If configure doesn't detect your case where a bump is necessary, re-run it
|
|
|
|
|
with the --enable-soname-bump command line option!
|
