Re: Question about curl_off_t
Date: Mon, 6 Aug 2007 16:45:26 +0200 (CEST)
On Mon, 6 Aug 2007, Patrick Monnerat wrote:
> It seems clear that the idea behind type curl_off_t is a 64bit integer on
> platforms supporting it. A 32bit type should only be used on platforms where
> no 64bit alternative exists.
> However, when compiling an application using libcurl, one may use "regular"
> 32bit IO and thus arrange to not define _LARGE_FILES, resulting in having a
> 32bit off_t ... and thus a 32-bit curl_off_t too.
Yes, this is a bit unfortunate. I've done some efforts to help this situation,
but it isn't an easy problem to solve nicely since there are so many systems
and too many of them can't run configure scripts...
I would even stretch it and claim that the problem is _really_ that we need to
set defines or use options or whatever to build a program with large file
support, as one would otherwise think that in 2007 we would always have large
file support unless we explicitly asked for compliance with something ancient.
Not that it helps us to whine, we still need to address the problem in our
> This is then in conflict with the libcurl compiled library, and may cause
> problem when passing curl_off_t values to curl_easy_setopt() (there may be
> other cases, but I did not check them all).
That's pretty much the culprit of the problem, yes.
> The current implementation forces calling applications to be compiled in
> _LARGE_FILES mode.
Yes, or however you enable it for applications.
> I think curl_off_t type (and associated values) must be determined at
> configure time, then substituted into the curl.h header file, in order to
> always have coherent definitions. For example from a curl.h.in file... any
> other clever idea ???
I did some work on a system like that a while ago, and I'm sure we can take it
up again from where I left it:
I believe the basic question that remain to be solved is how we make the
curl/config.h file nicely for non- configure systems.
-- Commercial curl and libcurl Technical Support: http://haxx.se/curl.htmlReceived on 2007-08-06