My general opinion of large-file support for Wget is comes from my
recent experience with large-file support for the Info-ZIP [Un]Zip
programs.
> Should Wget support systems without a 64-bit integer type?
Unless it's too difficult. (So, yes.)
The Info-ZIP programs define types, zoff_t and uzoff_t, which are
used for all file-size-related values. They're OS-dependent, but
usually they're done as "typedef off_t zoff_t;", and so on. On VMS, for
example, the actual size depends on a macro, _LARGEFILE which is defined
(or not) by the user when the programs are built. It's similar (but
different) in most places. A "configure" script can decide
automatically, if desired.
> What about the systems where third-party compilers, such as GCC,
> support a `long long' type, but printf is unable to print it?
In the Info-ZIP programs, the conditional formatting code is confined
to a function which takes a zoff_t value and returns a string. Thus, a
typical printf() might look like this:
zoff_t s;
printf( " File size is %s.\n", zip_fzofft( s, NULL, "u"));
The other function arguments control various formatting options. (Where
can't GCC printf() using "%ll"?)
> Should we support 32-bit-only systems to an extent where it would at
> least be possible to correctly *show* the size of a 2G+ file and perhaps
> download parts of it?
I'd say a nice error message would be simpler and better than failing
to download the file as requested.
> Do we even use off_t, given that it's always 32-bit on Windows?
I normally don't touch the Windows code, but I see stuff like this in
its osdep.h:
[...]
#ifdef LARGE_FILE_SUPPORT
/* 64-bit Large File Support */
/* Only types and the printf format stuff go here. Functions
go in tailor.h until ANSI prototypes are required and OF define
can go. */
# if (defined(__GNUC__) || defined(ULONG_LONG_MAX))
/* GNU C */
/* base types for file offsets and file sizes */
typedef long long zoff_t;
typedef unsigned long long uzoff_t;
/* 64-bit stat struct */
typedef struct stat z_stat;
/* printf format size prefix for zoff_t values */
# define ZOFF_T_FORMAT_SIZE_PREFIX "ll"
# elif (defined(__WATCOMC__) && (__WATCOMC__ >= 1100))
/* WATCOM C */
/* base types for file offsets and file sizes */
typedef __int64 zoff_t;
typedef unsigned __int64 uzoff_t;
/* 64-bit stat struct */
typedef struct stat z_stat;
/* printf format size prefix for zoff_t values */
# define ZOFF_T_FORMAT_SIZE_PREFIX "ll"
# elif (defined(_MSC_VER) && (_MSC_VER >= 1100)) || defined(__MINGW32__)
/* MS C and VC */
/* base types for file offsets and file sizes */
typedef __int64 zoff_t;
typedef unsigned __int64 uzoff_t;
/* 64-bit stat struct */
typedef struct _stati64 z_stat;
/* printf format size prefix for zoff_t values */
# define ZOFF_T_FORMAT_SIZE_PREFIX "I64"
# elif (defined(__IBMC__) && (__IBMC__ >= 350))
[...]
I gather that "%I64" is actually used as a format spec in some place or
other. (Gack.)
On the systems about which I care, off_t is fine, however. (That's
probably why the Info-ZIP folks chose to use zoff_t instead of plain
off_t, of course.)
> All of the above problems are possible to solve, but they are not easy,
> and they didn't seemed to be covered by the patches I'd had a chance to
> review.
I don't claim that it's a perfect scheme, but it would probably pay
to look at the beta code for Zip 3.0 and/or UnZip 6.0 to see how these
things are done in a _very_ portable program. (Before doing something
even more lame.)
PS:
Sorry to hear about the health failure. Suffering may build
character, but sometimes you just don't need any more character.
------------------------------------------------------------------------
Steven M. Schweda (+1) 651-699-9818
382 South Warwick Street [EMAIL PROTECTED]
Saint Paul MN 55105-2547
