2009/4/3, Stefan Teleman wrote:

> > 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
> now.

Very literally and strictly speaking I understand your point of view.
But you should also take in consideration that there are many cases in
which the underlying data type signness and width of the 'new'
curl_off_t is the same as that of the 'old' curl_off_t. Where 'old' is
pre-7.19.0 and 'new' is 7.19.0 and later. So, when the underlying
representation matches there is no actual ABI break.

For the rest of this message and the rest of this issue I ask you to
please make an effort and stop thinking which was the origin and the
definition of something named 'curl_off_t'.

Of course I'll also make the effort and from now on I'll talk about a
data type named 'curl_abstract_t'.

'curl_abstract_t' must be a signed integral data type with a 64-Bit
size for configurations which have such a native data type, and a
signed integral data type with a 32-Bit size for configurations which
do not have a 64-Bit native data type.

Given the above definition of 'curl_abstract_t'. Would the following
block of preprocessor directives properly describe the definition?

#if defined(__SUNPRO_C) || defined(__SUNPRO_CC)
# if defined(_LP64)
# define CURL_SIZEOF_LONG 8
# define CURL_TYPEOF_CURL_ABSTRACT_T long
# define CURL_SIZEOF_CURL_ABSTRACT_T 8
# elif defined(__STDC__) && (__STDC__ == 1)
# define CURL_SIZEOF_LONG 4
# define CURL_TYPEOF_CURL_ABSTRACT_T long
# define CURL_SIZEOF_CURL_ABSTRACT_T 4
# else
# define CURL_SIZEOF_LONG 4
# define CURL_TYPEOF_CURL_ABSTRACT_T long long
# define CURL_SIZEOF_CURL_ABSTRACT_T 8
# endif
#endif

Above definitions should hold the same regardless and independent of
large file support settings and should also take in account old
compiler versions.

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

It is a cURL problem as soon as users of libcurl binary distributions,
provided by others, get funny crashes and come here for help and
advice.

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

I haven't looked up in which moment such reasonable application
introduced the check. But I can positively tell you that libcurl
7.19.0 introduced it in such a way that the check is done both at
library compilation time and when an app is compiled against libcurl
ensuring a perfect match on those platforms capable of running
configure.

It is the responsibility of the binary packager distributing the
generated headers with the generated library. Taking in account that
each library has its set of unique libcurl headers.

As a matter of fact, only those systems which are not capable of
running a configure script should have their compilers included in
curlbuild.h.dist. This was the reason for not including Sun compilers
in such file in libcurl versions 7.19.0, 7.19.1 and 7.19.2.

But if a specific compiler is present in curlbuild.h.dist and at the
same time it is possible to run the configure script, then the
'curl_abstract_t' definitions must be identical.

-- 
-=[Yang]=-