2008/6/3, Dan Fandrich wrote:

> But which does determine whether curl_off_t is 32 bits or 64 bits under
> this new approach? Is it the availability of a 64 bit type? Or is it
> the availability of a 64 bit off_t type, signifying the ability of the
> system to handle large files?

The approach that I am following is directly related to the
availability of a signed 64 bit data type, and under this approach
curl_off_t would not depend on the large file support of the compiler,
libc or OS.

For a given compiler capable of enabling and disabling LFS the
curl_off_t data type would be the same no matter if LFS is enabled or
disabled when building the library and would also be the same when
building an app that uses the library no matter if LFS is enabled or
disabled when building the app. This is the "only" benefit of doing
this.

As a matter of fact it would just be easier to say that curl_off_t no
longer represents the off_t data type of a given compilation. But it
will be true that curl_off_t will be capable of storing any value held
by an off_t for a given compilation.

Conceptually it would be easier to think of this "new" curl_off_t in
terms of ptr_diff_t instead of using off_t concepts. Or maybe even
better just a curl_big_t that will have a fixed width given a
compilation target. The width might be 64, 32 or 16 bit wide depending
on the availability of such a data type native to the compiler.

I hope this make this approach a little bit more clear.

-- 
-=[Yang]=-