> > Note that I've also included support for specifying resume offsets which are
> > larger than 2 GB, which means that the Curl_setopt function has changed the
> > sizes of some of its arguments from long to off_t. I've attempted to update
> > the documentation for the relevant option keys in addition to changing the
> > keys themselves.
>
> Here's where I would like to chime in! I would rather have new options that
> set sizes that use a type different from 'long', to prevent a lot of
> applications to break when updating to this new version. The old (current)
>
> ...
>
> Perhaps appending "_BIG" is fine? Or "_NEW"?

Makes sense to me. I actually thought of application incompatibility
shortly after I submitted the patch the first time around. Too bad I
didn't think of it *before* I submitted the patch... :)

If it were entirely left to me, I'd go for adding "_BIG" rather than
"_NEW", since "_BIG" is a bit better of a description of what the
difference is between the two versions of like-named keys. The change
itself should be *very* easy, as you commented, especially since we can
easily populate an internal library off_t with a value read from a long,
so the two keys would really operate the same way aside from what they
read off the argument stack. Unless there is a need to have the internal
library structures retain the long versions of their fields in addition to
off_t versions...?

I'll proceed with _BIG version, leaving the internals converted to off_t
and submit another version of the patch. Unless I hear otherwise about
parts of that, of course. :)

> I would also like to see the 'off_t' handling get its own CURLOPTTYPE in the
> curl.h file (similar to how CURLOPTTYPE_OBJECTPOINT is used etc) so that it
> can be initialized like the rest in the option list in the header as well as
> parsed nicer in url.c:Curl_setopt().

Slick. I hadn't looked at how that part worked (no long->off_t
conversions needed there). I'll do as you suggest, make the new
CURLOPT_xxx things that way, and clean up my messiness for what things
need off_t's in the appropriate place.

> We also need to check for the strtoll() function in the configure script for
> this. (I'll add that check right now)

Wonderful! I was wondering if something like that would be necessary, but
sadly learning about auto{make,conf,etc.} is still on my list of TODOs
rather than my list of HAVE_DONEs...

Thanks,

Dave

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Received on 2003-12-10