On Tue, 27 May 2008, Yang Tse wrote:

> 1) The same definition of curl_off_t must be used when building the library
> and when an app uses libcurl's external API. This implies that libcurl's
> external API must define curl_off_t in the same way as it is defined when
> the library is built.

Correct. But the problem is that the original type we use for the typedef in
POSIX systems differ in size depending on defines (off_t).

> 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 guess we can use my posted 64bitskew patch as a basis for such a change.

> 9) Combination of this two properties results in four possible cases:
>
> 9a) 32 bit curl_off_t and 32 bit file offsets: No problem here, they match.
>
> 9b) 64 bit curl_off_t and 64 bit file offsets: No problem here, they match.

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.

> 11) Assuming that there are no errors in all the above reasoning we now get
> to the part of 'which was first the egg or the hen'. If we have a system
> capable of running the 'buildconf' generated 'configure' script we should
> 'use' the hen, otherwise we'll need an egg for each system. And there's also
> the case of the cross-compiling eggs with hens :-)

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.

-- 
  / daniel.haxx.se