On Tue, 27 May 2008, Yang Tse wrote:

>> Yes, that should be doable if we abandon the use of off_t for it. And given
>> the quirks we have atm, I figure that's a sensible way to proceed.
>
> I'm not proposing now abandoning the use of off_t for curl_off_t and setting
> it to something like int64_t. It could be done some day if the need actually
> arises, and not in feature freeze period. The only benefit that it would
> introduce would be that curl_off_t would no longer be a build-time property
> which further depends on other settings.

Well, this is the "only" problem we can solve in the headers I would think.

I fact, I think I'm starting to favour us switching to using a "fixed" type
for curl_off_t to more reliably avoid this problem in the future.

Also, let's not change anything of this in 7.18.2 anyway, to give us plenty of
time to discuss this issue further.

> In order for users to be capable of properly 'interfacing' an already built
> libcurl library it is necessary for them to include, via curl.h, the same
> settings that were used to build the library; and that in this specific case
> these are the ones relative to the LFS compiler settings and the
> typedef'inition of curl_off_t.

Perhaps, but if we use off_t for curl_off_t we can't just set the correct LFS
defines for the platform since users may then include headers before the curl
header(s) and would then risk getting a mixed set.

We would need to detect the skew and warn about it. That's what my current
patch tries to do.

> I'm not sure we'll be able to do it for all platforms, specially those
> without autotools support, but it should improve current situation for a big
> number of them.

The non-configure ones would basically remain working like today but I don't
think they are the problematic ones.

> Also storing the build-time sizes of off_t and curl_off_t will do no harm
> and might help at some point. But its still not clear to me that these are
> actually needed to perform any verification.
>
> The headers won't be able to check these at compilation time.

For POSIX systems: If the sizes of off_t and long were different at
configure-time and an application is built when no LFS-defines are detected,
then I think we can assume that there's a problem scenario.

> As Dan has already stated a good check would be a run-time check that lets
> the library, at some initialization point, verify discrepancies between
> library-build-time sizes of off_t and curl_off_t and those that the inking
> app is actually using for them, if both data type sizes don't match the
> initialization should fail.

I agree about that being the most fail-safe way, but that would mean a new
function (or multiple ones) in the API. Of course that's not a bad thing if it
makes the (using of the) lib better.

-- 
  / daniel.haxx.se