On Fri, 16 Jan 2004, Gisle Vanem wrote:

> > We currently use off_t for this, which clearly isn't good enough. Since we
> > don't pass this on to local I/O functions, perhaps we can simply use
> > 'pos_t' on windows and get away with it?
>
> Probably yes, and for resuming a download we must use _lseeki64() at
> file.c/line 238.

That's for resuming a "download" from a file:// URL, but you're right.

The only annoying part of going with pos_t for Windows is the mess this causes
in the source code. Sure, we can create an internal typedef called filesize_t
or something (like some #if 0'ed code in setup.h already attempts to do) to
hide the differences between platforms but for the public API I would rather
use well known and widely used types for this kind of data... which happens to
be off_t on *nix systems. Is pos_t "widely known" for large file size types on
Windows? If not, what type would a typical Windows developer use to store
(large) file sizes?

That type would be used in the documentation for the setopt options that allow
large file sizes, and then we'd typecast a conversion in the code from that
pos_t to filesize_t and use filesize_t all over the internals...

> It's really 'fpos_t' and for MingW/MSVC it's 64-bit signed. But only 32 bits
> for Watcom (but Watcom doesn't use MSVCRT.DLL so I'm not sure it handles
> >2GB files anyway).

I get dizzy of all these types. What type would we tell Windows developers to
use? Would that be a different type depending on what compiler/development
environment the poor user sits in front of?

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn