Re: Large Files Support for Wget
On Tue, 11 May 2004, Hrvoje Niksic wrote: That in itself is not a problem because, under Windows, off_t will be typedeffed to a 64-bit type if LFS is available, and to `int' otherwise. Sorry for my confusion, but when I think about it I believe Windows _do_ have an off_t, but that is merely 32bit. The plain libc in Windows seem to be limited to 32 bits, even though the actual underlying code support 64bit sizes. In curl we work around this by providing our own curl_off_t variable. The point of my question was: should low-level code even care whether LFS is in use (by using off_t for various variables), or should it use intmax_t to get the largest representation available on the system? The latter is in principle sort of like using `long', except you're not tied to the actual size of `long'. In curl we went with curl_off_t for various variables and that is then 32bit or 64bit depending on platform. I can't see many benefits in using 64bit variables on systems that don't deal with 64bit filesizes. -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Re: Large Files Support for Wget
Daniel Stenberg [EMAIL PROTECTED] writes: On Mon, 10 May 2004, [iso-8859-2] Dra?en Ka?ar wrote: * Change most (all?) occurrences of `long' in the code to `off_t'. Or should we go the next logical step and just use uintmax_t right away? Just use off_t. ... but Windows has no off_t... ;-) That in itself is not a problem because, under Windows, off_t will be typedeffed to a 64-bit type if LFS is available, and to `int' otherwise. The point of my question was: should low-level code even care whether LFS is in use (by using off_t for various variables), or should it use intmax_t to get the largest representation available on the system? The latter is in principle sort of like using `long', except you're not tied to the actual size of `long'.
RE: Large Files Support for Wget
-Original Message- From: Hrvoje Niksic [mailto:[EMAIL PROTECTED] * Profit! I think you'd really deserve some. Heiko -- -- PREVINET S.p.A. www.previnet.it -- Heiko Herold [EMAIL PROTECTED] [EMAIL PROTECTED] -- +39-041-5907073 ph -- +39-041-5907472 fax
Re: Large Files Support for Wget
Hrvoje Niksic wrote: David Fritz [EMAIL PROTECTED] writes: IIUC, GNU coreutils uses uintmax_t to store large numbers relating to the file system and prints them with something like this: char buf[INT_BUFSIZE_BOUND (uintmax_t)]; printf (_(The file is %s octets long.\n), umaxtostr (size, buf)); That's probably the most portable way to do it. For the time being. However, in C99 %ju is the correct format for printing uintmax_t. There are systems which have uintmax_t, but don't have the j modifier, so the whole thing is a problem if you want to write failsafe configure check. And there might be run-time problems, as well. * Change most (all?) occurrences of `long' in the code to `off_t'. Or should we go the next logical step and just use uintmax_t right away? Just use off_t. -- .-. .-.Yes, I am an agent of Satan, but my duties are largely (_ \ / _) ceremonial. | |[EMAIL PROTECTED]
Re: Large Files Support for Wget
On Mon, 10 May 2004, [iso-8859-2] Dra?en Ka?ar wrote: * Change most (all?) occurrences of `long' in the code to `off_t'. Or should we go the next logical step and just use uintmax_t right away? Just use off_t. ... but Windows has no off_t... ;-) -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Re: Large Files Support for Wget
IIUC, GNU coreutils uses uintmax_t to store large numbers relating to the file system and prints them with something like this: char buf[INT_BUFSIZE_BOUND (uintmax_t)]; printf (_(The file is %s octets long.\n), umaxtostr (size, buf)); where umaxtostr() has the following prototype: char *umaxtostr (uintmax_t, char *); and it returns its second argument (the address of the buffer provided by the caller) so it can be used easily as an argument in printf calls.
Re: Large Files Support for Wget
David Fritz [EMAIL PROTECTED] writes: IIUC, GNU coreutils uses uintmax_t to store large numbers relating to the file system and prints them with something like this: char buf[INT_BUFSIZE_BOUND (uintmax_t)]; printf (_(The file is %s octets long.\n), umaxtostr (size, buf)); That's probably the most portable way to do it. I guess that solves the remaining technical difficulty. The things that need to be done for large file support then are: * Use AC_SYS_LARGEFILE in configure.in. Make sure the compilation flags contain the proper large file support incantations. * Change most (all?) occurrences of `long' in the code to `off_t'. Or should we go the next logical step and just use uintmax_t right away? * Profit! Some of this has already been done in the submitted patch.
Re: Large Files Support for Wget
[ Moving discussion to [EMAIL PROTECTED] ] Gisle Vanem [EMAIL PROTECTED] writes: Hrvoje Niksic [EMAIL PROTECTED] said: Supporting large files in a really portable manner is unfortunately not trivial. It's not that hard. Look at how we did this in libcurl; basically some define trickery; #define FILE_OFF_T 32/64 bit unsigned Fair enough. But isn't off_t signed? #define FILE_OFF_FMT %llu or %Lu How does gettext cope with that? For example, this string is what worries me: printf (_(The file is FILE_OFF_FMT octets long.\n), size);
Re: Large Files Support for Wget
Hrvoje Niksic [EMAIL PROTECTED] said: #define FILE_OFF_T 32/64 bit unsigned Fair enough. But isn't off_t signed? Obs, yes. A 'long' on Win32. #define FILE_OFF_FMT %llu or %Lu How does gettext cope with that? For example, this string is what worries me: printf (_(The file is FILE_OFF_FMT octets long.\n), size); I assume Wget needs a msg-entry for each string. The file is %Ld octets long.\n The file is %lld octets long.\n unless messages is built on same platform as Wget is. Not sure this is possible with the msg* tools. --gv
Re: Large Files Support for Wget
Gisle Vanem [EMAIL PROTECTED] writes: printf (_(The file is FILE_OFF_FMT octets long.\n), size); I assume Wget needs a msg-entry for each string. The file is %Ld octets long.\n The file is %lld octets long.\n The problem is, which of those message entries should end up in `wget.pot' and in translations? unless messages is built on same platform as Wget is. Even if messages are, translations are probably not.
