2008/5/27, Daniel Stenberg wrote:

> 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.

I suppose that there are still some systems where there might not
exist a 64bit integral type. So falling back to 32 or even 16bits
would be probably needed.

curl_off_t would actually be "fixed per system" making it independent
of library builder and library user choices. I also think this is a
step in the right direction.

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

If it is going to be "fixed" I certainly agree on this. But I would
also suggest another thing... If its going to be "fixed" lets do it
nearly the first thing after the release of 7.18.2, for two reasons,
first is autobuilds would be stable enough to quickly detect problems,
and second there would be plenty of time to further discover potential
problems on systems not on the autobuild system.

> > 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.

Ah, yes certainly. The issue here is that whoever builds the library
dictates how it must be used. To stay on the safe side both, library
and app, must be LFS enabled or disabled.

If we keep record of the LFS setting at library build time or not is
actually a different issue.

As a matter of fact, checking at run-time if the size of off_t is
different for the library and the app should be good enough to detect
conflicting LFS settings between library and app.

> 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.

Dan was suggesting doing the check at curl_easy_init() stage. Is there
any reason for not doing it simply once at curl_global_init() ?

Another type whose size also should probably be verified is time_t.

-- 
-=[Yang]=-