On Thu, 21 Aug 2008, Yang Tse wrote:

> Since we already have CURL_SIZEOF_CURL_OFF_T in use for the size of
> curl_off_t. Would it be all right to use CURL_SIZEOF_SYST_OFF_T for
> the size of off_t or would it be preferable to just use
> CURL_SIZEOF_OFF_T ?

I think the latter, to use the same naming approach.

> Things might start getting quite confusing. Specially because we still have
> CURL_FORMAT_OFF_T around for backwards compatibility reasons, which is
> actually used for the format of curl_off_t. Eeek!

Right, but we could define it with a large comment saying it's only present
for backwards compatibility reasons and make sure we use more a sensibly named
define ourselves.

> The CURL_SIZEOF_SYST_OFF_T definition placed by configure in the generated
> curlbuild.h is certainly going to help library users which can run
> configure, or someone has run configure for them, to detect at compile time
> if they are properly using the library or not.

What specifics break if the app is built with a 32bit off_t while libcurl uses
64bit? Previously this broke because curl_off_t reasons, but with curl_off_t
separated from that issue I can't think of a reason why this won't work. Or
have I just not thought this through properly?

> For non-configure systems, the ones which will actually be using the renamed
> curlbuild.h.dist the check is ineffective due to the fact that
> curlbuild.h.dist has to make the proper definitions no matter which data
> model is used and no matter if LFS is enabled or not.

I don't think we should worry too much about those systems. I don't think we
ever even have seen anyone with a non-configure system attempt to change the
LFS-status of the build, and I'm convinced most users (compilers of libcurl)
won't and won't even see a need for it.

For those systems I think we can assume that the ones building libcurl will
use our provided headers and build choices as far as possible, and editing the
LFS status is certainly not something our files encourage.

> IOW, for non-configure systems the runtime check at library initialization,
> that Dan Fandrich suggested some time ago, is additionally required if we
> want to certainly make sure that no app is misusing the library. At least
> the sizes of long and off_t should probably be verified.

A) long? Do we really have systems that can get built with different sizes of
long?

B) off_t - see above.

But yeah, the ultimate fool-proof way will require something like that. I am
however fine with something that will cover 99%, and I think by having
configure do right and having all our delivered config files do right we will
easily reach that.

-- 
  / daniel.haxx.se