Date: Fri, 22 Aug 2008 14:43:18 +0200
2008/8/22, Daniel Stenberg wrote:
> On Thu, 21 Aug 2008, Yang Tse wrote:
> > [...]
> > 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.
If we got rid of the "%" char it has inside... (which would somehow
break absolute backwards compatibility) we could map it to the format
of off_t which after all was the use for the old curl_off_t. But yes,
getting rid of the "%" char would break any app using old
CURL_FORMAT_OFF_T. I suppose we'll have to live with it until
> > 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?
Only when using curl_read_callback or curl_write_callback, if app is
using a 32bit off_t read/write IO function it might fail as soon as it
reaches the 2Gb, or at the very first read/write as the IO library
might think the file is not open. It much depends on how the LFS is
implemented in the system IO library, and if the IO library is
statically or dynamically linked.
> > 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?
From the autobuilds...
HP-UX B.11.23 [64bit]
HP-UX B.11.23 [32bit]
> B) off_t - see above.
Se below ;-)
Again from the autobuilds...
IRIX 6.2 MIPS C 6.2 o32
IRIX 6.2 MIPS C 6.2 n32
> 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.
It can always be added at a later moment.
-- -=[Yang]=-Received on 2008-08-22