2008/5/27, Daniel Stenberg wrote:

> On Tue, 27 May 2008, Yang Tse wrote:
>
> > 3) We could say that the curl_off_t definition is a build-time property
> > of the library. And that under most circumstances it will be a 32 or
> > 64 bits signed integral data type.
>
> 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.

What I was actually trying to transmit is that...

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.

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.

> I guess we can use my posted 64bitskew patch as a basis for
> such a change.

Yes of course. I'll study it once you make any additional comment to this post.

> Well, curl_off_t SHOULD match the "file offset" type on all systems
> whatever the size. Everything else is an error, and while we should
> do our best to survive that situation as well it should still be rare.

This is the crystal clear statement that I was awaiting in the whole thread.

> Well, I think we should let configure figure out the sizes and generate
> them in the headers. It will make headers that are specific for a
> particular libcurl build, but in practise I don't think that is a problem
> to very many people.

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.

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 see this last check important and complimentary to the ability to
help link an app with the same settings as the library was built.

-- 
-=[Yang]=-