cURL / Mailing Lists / curl-library / Single Mail


Re: Potential ABI break for libcurl Sun Compiler users

From: Stefan Teleman <>
Date: Fri, 3 Apr 2009 03:17:19 -0400

On Fri, Apr 3, 2009 at 02:01, Yang Tse <> wrote:
> 2009/4/3, Stefan Teleman wrote:
>> So how often do you guys break ABI ? Inquiring minds want to know.
>> It sounds like you don't care at all that 7.19.x breaks ABI with
>> earlier releases.
> Cool down.
> The ABI breakage takes place only in some very specific cases for some
> platforms. Depending on how each packager was previously building the
> library there would be an ABI breakage or not.

Nope, it doesn't break down in "very specific cases". It breaks down
the moment you change the underlying datatype of curl_off_t which used
to be the semi-native off_t, to whatever you have decided it should be

> In this particular case consider that another option would have been
> to replace all curl_off_t literals inside and outside the library with
> int64_t. Would this have made people more happy?

No, and that would be completely wrong, since sizeof(off_t) for 32-bit
without _LARGEFILE_SOURCE or __EXTENSIONS__ != sizeof(int64_t).

> I guess not, as it
> would have forced everyone using libcurl to also replace the
> curl_off_t strings in their apps and surely rebuild.
>> Your patch is still fundamentally wrong,
> Describe why.

I already have. long long is not available for strict compilation
environments prior to C99, which the Sun compilers support. Also, your
patch doesn't solve the problem at hand (it does and cannot enforce a
consistent size for curl_off_t across different compilation
environments, but introduces an unnecessary ABI breakage. It also
#defines CURL_SIZEOF_LONG 4 twice, although the macros are identical.

The only discriminant for sizeof(off_t) in 32-bit is whether or not


> We know how curl_off_t is used inside of libcurl. We know the problems
> that represented having it defined as it was in the pre-7.19.0 days,
> mostly unexplainable bugs or coredumps when the library user compiled
> an app with different settings than those used to build the library.

And this isn't a CURL problem, this is a compiler flags consistency
problem. This compiler flags dependency problem is not specific to
CURL, it exists in many other libraries. This is why reasonable
applications, like for example PHP, perform their own
sizeof(curl_off_t) checks at compile-time, specifically for CURL, and
error the compilation if the bitness size doesn't match.

This is exactly the reason why the semi-native type off_t [ it's a
typedef, and it is correctly typedef'ed in Solaris header files,
conditional on all possible compilation environment combinations ] was
invented in the first place: so that developers do not have to bother
writing insane workarounds.

You should have left it exactly the way it was prior to 7.19.0: a
typedef for off_t -- whatever the size of off_t happened to be, at
./configure time. You can easily express the restrictions for the
implicit size of curl_off_t (off_t) by providing the additional
required compiler flags (-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64)
either in curl-config or in libcurl.pc, as grep'ed from ./configure.

It is completely harmless (and also useless) to raise
_FILE_OFFSET_BITS=64 or _LARGEFILE_SOURCE when compiling 64-bit,
either for __sparcv9 or for __amd64/__x86_64__. In these compilation
environments, sizeof(off_t) is always 8 bytes. Therefore, raising
these macros in 64-bit mode has no effect.

Stefan Teleman
KDE e.V.
Received on 2009-04-03