| 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768 |
- 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
- -------------------------------------
- Applications that used libcurl before 7.19.0 that are rebuilt with a libcurl
- 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
- and transparent.
- 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
- 64bit where it previously was 32bit. This will cause a binary incompatibility
- that you MAY need to deal with.
- Benefits
- --------
- This new way has several benefits:
- o Platforms without LFS support can still use libcurl to do >32 bit file
- transfers and range operations etc as long as they have >32 bit data-types
- 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
- Historically
- ------------
- 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.
- SONAME
- ------
- 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!
|
