New version of LFS patch
Here is the new version of the patch, with print_*_number_to_string
replaced with a single number_to_static_string, which does the buffer
ring stunt we discussed (and has a more accurate name to boot).
Please try it out and let me know if it works for you. I'd especially
be interested in compilation reports from 64-bit systems, systems
without LFS, and non-Linux systems. Tips for making it work on
Windows would also be appreciated.
Mauro, what do you think of the patch? If you agree with the patch,
I'd like to commit it to CVS once it gets sufficient testing.
ChangeLog:
2005-02-20 Hrvoje Niksic [EMAIL PROTECTED]
* configure.in: Check for LFS. Determine SIZEOF_OFF_T.
src/ChangeLog:
2005-02-20 Hrvoje Niksic [EMAIL PROTECTED]
* wget.h: Define a `wgint' type, normally aliased to (a possibly
64-bit) off_t.
* all: Use `wgint' instead of `long' for numeric variables that
can hold file sizes.
* utils.c (number_to_string): Accept a `wgint' number argument.
(number_to_static_string): New function.
* all: Replace printf(%ld, long_value) with printf(%s,
number_to_static_string(wgint_value)).
Index: configure.in
===
RCS file: /pack/anoncvs/wget/configure.in,v
retrieving revision 1.73
diff -u -r1.73 configure.in
--- configure.in2003/11/26 22:46:13 1.73
+++ configure.in2005/02/20 13:44:15
@@ -183,6 +183,14 @@
AC_CHECK_SIZEOF(long long)
dnl
+dnl Check for large file support. This check needs to come fairly
+dnl early because it could (in principle) affect whether functions and
+dnl headers are available, whether they work, etc.
+dnl
+AC_SYS_LARGEFILE
+AC_CHECK_SIZEOF(off_t)
+
+dnl
dnl Checks for non-universal or system-specific types.
dnl
AC_TYPE_SIZE_T
Index: src/ftp-basic.c
===
RCS file: /pack/anoncvs/wget/src/ftp-basic.c,v
retrieving revision 1.36
diff -u -r1.36 ftp-basic.c
--- src/ftp-basic.c 2003/11/21 01:48:05 1.36
+++ src/ftp-basic.c 2005/02/20 13:44:16
@@ -897,15 +897,13 @@
/* Sends REST command to the FTP server. */
uerr_t
-ftp_rest (int csock, long offset)
+ftp_rest (int csock, wgint offset)
{
char *request, *respline;
int nwritten;
uerr_t err;
- static char numbuf[24]; /* Buffer for the number */
- number_to_string (numbuf, offset);
- request = ftp_request (REST, numbuf);
+ request = ftp_request (REST, number_to_static_string (offset));
nwritten = fd_write (csock, request, strlen (request), -1);
if (nwritten 0)
{
@@ -1114,7 +1112,7 @@
/* Sends the SIZE command to the server, and returns the value in 'size'.
* If an error occurs, size is set to zero. */
uerr_t
-ftp_size (int csock, const char *file, long int *size)
+ftp_size (int csock, const char *file, wgint *size)
{
char *request, *respline;
int nwritten;
@@ -1150,7 +1148,7 @@
}
errno = 0;
- *size = strtol (respline + 4, NULL, 0);
+ *size = str_to_wgint (respline + 4, NULL, 0);
if (errno)
{
/*
Index: src/ftp-ls.c
===
RCS file: /pack/anoncvs/wget/src/ftp-ls.c,v
retrieving revision 1.28
diff -u -r1.28 ftp-ls.c
--- src/ftp-ls.c2004/12/09 01:20:39 1.28
+++ src/ftp-ls.c2005/02/20 13:44:18
@@ -213,7 +213,7 @@
if (i != 12)
{
char *t = tok - 2;
- long mul = 1;
+ wgint mul = 1;
for (cur.size = 0; t line ISDIGIT (*t); mul *= 10, t--)
cur.size += mul * (*t - '0');
@@ -368,14 +368,14 @@
if (!dir)
{
- l = dir = (struct fileinfo *)xmalloc (sizeof (struct fileinfo));
+ l = dir = xnew (struct fileinfo);
memcpy (l, cur, sizeof (cur));
l-prev = l-next = NULL;
}
else
{
cur.prev = l;
- l-next = (struct fileinfo *)xmalloc (sizeof (struct fileinfo));
+ l-next = xnew (struct fileinfo);
l = l-next;
memcpy (l, cur, sizeof (cur));
l-next = NULL;
@@ -517,9 +517,9 @@
else
{
cur.type = FT_PLAINFILE;
- cur.size = atoi(tok);
+ cur.size = str_to_wgint (tok, NULL, 10);
cur.perms = 0644;
- DEBUGP((File, size %ld bytes\n, cur.size));
+ DEBUGP((File, size %s bytes\n, number_to_static_string (cur.size)));
}
cur.linkto = NULL;
@@ -527,14 +527,14 @@
/* And put everything into the linked list */
if (!dir)
{
- l = dir = (struct fileinfo *)xmalloc (sizeof (struct fileinfo));
+ l = dir = xnew (struct fileinfo);
memcpy (l, cur, sizeof (cur));
l-prev = l-next = NULL;
}
else
{
cur.prev = l;
- l-next = (struct fileinfo *)xmalloc (sizeof (struct fileinfo));
+
Windows and long long
Does MSVC support long long? If not, how does one... * print __int64 values? I assume printf(%lld, ...) doesn't work? * retrieve __int64 values from strings? I assume there is no strtoll? I'm asking because I noticed that my LFS patch kind of depends on long long on machines with LFS.
Re: Windows and long long
Hrvoje Niksic wrote: Does MSVC support long long? If not, how does one... No, it has a '__int64' built-in. * print __int64 values? I assume printf(%lld, ...) doesn't work? Correct, use %I64d for signed 64-bit and %I64u for unsigned. * retrieve __int64 values from strings? I assume there is no strtoll? No, but MSVC7 has a __int64 __cdecl _strtoi64(const char *str, char **endptr, int base); MingW and Watcom have strtoll(). For MSVC6 one could use sscanf (str,%I64d,val); --gv
Re: Gmane
Hello Hrvoje, wishing you all well! On Saturday, February 19, 2005 at 6:20:52 PM +0100, Hrvoje Niksic wrote: I propose to make this list available via gmane, www.gmane.com. It buys us good archiving, as well as NNTP access. Is there anyone who would object to that? There are pros and cons. Wider audience and potential contributors. But greater exposition to spam, both of the list and it's members. And that infamous gmane message-id overwriting, that breaks our threads. BTW Hrvoje, do you want a gzipped mbox of missed wget-patches posts? Please give me date boundaries, I'll be happy to help. Bye!Alain. -- Microsoft Outlook Express users concerned about readability: For much better viewing quotes in your messages, check the little freeware program OE-QuoteFix by Dominik Jain on URL:http://flash.to/oblivion/. It'll change your life. :-) Now exists also for Outlook.
Re: Windows and long long
Gisle Vanem [EMAIL PROTECTED] writes: Hrvoje Niksic wrote: Does MSVC support long long? If not, how does one... No, it has a '__int64' built-in. * print __int64 values? I assume printf(%lld, ...) doesn't work? Correct, use %I64d for signed 64-bit and %I64u for unsigned. * retrieve __int64 values from strings? I assume there is no strtoll? No, but MSVC7 has a __int64 __cdecl _strtoi64(const char *str, char **endptr, int base); Thanks for the info. Is it OK to just require MSVC7, or should we write a compatibility function for earlier versions? The nice thing about _strtoi64 is that its interface is compatible with strtoll, which means one can #define str_to_wgint to strtol, strtoll, or _strtoi64, as appropriate for the platform. One more question: how does one spell 64-bit constants in MSVC? google seems to suggest nnnI64; how portable is that?
Re: New version of LFS patch
El 20/02/2005, a las 15:02, Hrvoje Niksic escribió: Here is the new version of the patch, with print_*_number_to_string replaced with a single number_to_static_string, which does the buffer ring stunt we discussed (and has a more accurate name to boot). Please try it out and let me know if it works for you. Is this a patch against the current CVS version, or against 1.9.1? I get a whole stack of hunk FAILED warnings when I try to apply the patch to either one (just using patch -p0 patchfile). Here's the first few lines of the output, but you get the idea... patching file configure.in patching file src/ftp-basic.c patching file src/ftp-ls.c Hunk #1 FAILED at 213. Hunk #2 FAILED at 368. Hunk #3 FAILED at 517. Hunk #4 FAILED at 527. 4 out of 4 hunks FAILED -- saving rejects to file src/ftp-ls.c.rej patching file src/ftp.c Hunk #4 FAILED at 770. Hunk #6 FAILED at 1263. Hunk #8 succeeded at 1482 with fuzz 1. Hunk #9 FAILED at 1844. 3 out of 9 hunks FAILED -- saving rejects to file src/ftp.c.rej Greg
Re: Windows and long long
Gisle Vanem [EMAIL PROTECTED] writes: Hrvoje Niksic wrote: Thanks for the info. Is it OK to just require MSVC7, or should we write a compatibility function for earlier versions? Write a compatible function IMHO. A lot of users (including me) still uses MSVC6. OK. I don't think we can use sscanf, though, because strtol(l) supports (and Wget uses) overflow detection. One more question: how does one spell 64-bit constants in MSVC? google seems to suggest nnnI64; how portable is that? That can be expressed with: #if defined(_MSC_VER) || defined(__WATCOMC__) #define S64_SUFFIX(x) (x##i64) #define U64_SUFFIX(x) (x##Ui64) #else #define S64_SUFFIX(x) (x##LL) #define U64_SUFFIX(x) (x##ULL) #endif That won't work with old compilers which Wget still (unless Mauro has decreed otherwise) supports. Fortunately, I need 64-bit constants in only one place, which is now correctly ifdeffed.
Re: Large file support
[EMAIL PROTECTED] (Steven M. Schweda) writes: 1. I'd say that code like if ( sizeof(number) == 8 ) should have been a compile-time #ifdef rather than a run-time decision. Where do you see such code? grep 'if.*sizeof' *.c doesn't seem to show such examples. As I recall, it was in someone's suggested changes. Perhaps: http://software.lpetrov.net/wget-LFS/wget-LFS-20041113.patch Oh, OK. I thought you were referring to my LFS patch. The Info-ZIP code uses one function with a ring of string buffers to ease the load on the programmer. That makes sense. I assume the print function also receives an integer argument specifying the ring position? Why assume? Why not look? Sorry about that. It is no small task to study Info-ZIP's source code. I did plan to look at it later, but at the time it was quicker to just ask. You're right, that's much better. I've now written a new version that does away with the _second function. The caller still has to be aware of the ring size limitation, but that's hard to avoid without making the interface hairier. Say, is that wheel your own invention? It was proposed by Roman Bednarek in [EMAIL PROTECTED]. Anyway, why the unfriendliness? Again, sorry about not having had the time to study a large program like Info-ZIP. The LFS patch I'm working on is still in its infancy, and there is a lot of room for improvements.
Re: wget.1 translation
Am Mittwoch, den 09.02.2005, 10:40 +0200 schrieb Nick Shaforostoff: hi, i've translated wget.1 to Russian what should i do to get it added to the official wget distro? Just send your ru.po or a patch/diff to the po/ru.po in the wget cvs to [EMAIL PROTECTED] -- Nol Kthe noel debian.org Debian GNU/Linux, www.debian.org signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: New version of LFS patch
El 20/02/2005, a las 16:52, Hrvoje Niksic escribió: Greg Hurrell [EMAIL PROTECTED] writes: Is this a patch against the current CVS version, or against 1.9.1? It's against the current CVS version, sorry for having forgotten to point it out. Perhaps you've forgotten to run cvs update? No. Must be some other weirdness on my system. This is on a freshly checked-out copy: $ cvs -d :pserver:[EMAIL PROTECTED]:/pack/anoncvs login (Logging in to [EMAIL PROTECTED]) CVS password: $ cvs -d :pserver:[EMAIL PROTECTED]:/pack/anoncvs co wget cvs server: Updating wget U wget/AUTHORS U wget/COPYING [lots of CVS output] U wget/windows/config.h.ms U wget/windows/wget.dep $ cd wget $ patch -p0 ../LFS-patch patching file configure.in patching file src/ftp-basic.c patching file src/ftp-ls.c Hunk #1 FAILED at 213. Hunk #2 FAILED at 368. Hunk #3 FAILED at 517. Hunk #4 FAILED at 527. [lots more of the same] No idea what's wrong here... Perhaps it's just not my destiny to have the patch apply! ;-) Cheers, Greg
Re: New version of LFS patch
Greg Hurrell [EMAIL PROTECTED] writes: No. Must be some other weirdness on my system. [...] Maybe your mail client mangled the long lines in the patch? Try to download the patch from here and see if it works then: http://fly.srk.fer.hr/~hniksic/lfs-patch
string_t breaks compilation under Solaris
string_t.c uses the function iswblank, which doesn't seem to exist on Solaris 8 I tried to compile it on. (Compilation is likely broken on other non-Linux platforms as well for the same reason.) Since nothing seems to be using the routines from string_t, I solved the problem by removing string_t.o from Makefile. If portability is still desired for Wget, it would IMHO be a good idea to completely remove the dependency on wide characters.
Re: Large file support (was Re: Back after a while)
Dave Yeo [EMAIL PROTECTED] writes: ps anyone getting a bunch of what look like viruses on the wget-patches list? I just noticed them on gmane. I've now asked the SunSITE.dk staff to deploy the kind of virus/spam protection currently used by this list (confirmation required for non-subscribers to post), which seems to work well.
Re: -X regex syntax? (repost)
On Fri, 18 Feb 2005, [ISO-8859-1] Jens Rösner wrote: } Hi Vince! } } I did give -X*backup a try, and } it too didn't work for me. :( } } Does the -Xdir work for you at all? } If not, there might be a problem with MacOS. } I hope one of the more knowledgeable people here } can help you! I've tried both on my Mac OS X box and Linux box, and the problem is still there. It appears that -X will work if you know the exact name and path of the directory, but that is not entirely the case with my problem. I need to be able to not download any and all directories named .backup. There are many of them in different paths, so I figured I need some kind of regex as -X.backup is not enough. Does anyone here know what syntax wget's regex engine uses? I have not been able to find any documentation about it. Thanks, /vjl/
Re: string_t breaks compilation under Solaris
On Sunday 20 February 2005 06:31 pm, Hrvoje Niksic wrote: string_t.c uses the function iswblank, which doesn't seem to exist on Solaris 8 I tried to compile it on. (Compilation is likely broken on other non-Linux platforms as well for the same reason.) Since nothing seems to be using the routines from string_t, I solved the problem by removing string_t.o from Makefile. i know, i still have to add autoconf tests for support of iconv(3) and wide chars. If portability is still desired for Wget, it would IMHO be a good idea to completely remove the dependency on wide characters. backwards compatibility towards old and legacy systems is and will always be a primary concern for wget, at least as long as i am the maintainer. however, i really think we need to support string escape when printing data coming from a possibly unsafe source (e.g. a server) to the console. please read this thread: http://www.mail-archive.com/wget%40sunsite.dk/msg06953.html simone piunno (included in cc) and i have been thinking to adopt the following behaviour: if the current system supports iconv(3) AND wide chars: when we are printing to a tty (try to) interpret all the strings coming from a possibly unsafe source according to the local charset (this involves a MBR to WIDE CHAR translation) escaping the unprintable chars, then store the escaped string using UTF8 encoding (which allows the escaped strings to be interpolated within the strings retrieved via gettext - which need to be UTF8 encoded as well). the adoption of UTF8 as an internal encoding for wget strings forces us to perform decoding from UTF8 every time we print the strings. please notice that by adopting this policy we will not be able to rely on I/O functions from the standard C library anymore. instead, we will have to develop our own output functions. this is not so bad as it seems, since IIRC wget uses only the logprintf function to print output on the screen or in a log file. i've taken a deep look at the logprintf calls wget makes: http://www.mail-archive.com/wget%40sunsite.dk/msg06977.html and as you can see the only formats wget uses are: '%5ld', '%%', '%d', '%ld', '%2d', '%.2f', '%3d', '%c', '%s', '%*s' so, i was working on a simplified version of the dopr function contained in the snprintf module to be used by a new version of logprintf (this function would support only the above mentioned formats and escape a given string when using a special format - i used %es), but my laptop broke (i accidentall poured some water on it and the HDD is unrecoverable) before i could commit the code to CVS. else (if the current system does not support iconv(3) OR wide chars): when we are printing to a tty (try to) perform escaping of the strings coming from a possibly unsafe source according to the ASCII charset (that is, escape unprintable ASCII chars). no need to adopt UTF8 encoding or implement any special output functions. what do you think? any comments or questions? P.S. i am very sorry if you haven't heard any news from me lately but it seems that i've catched a very bad flue that when gone away keeps coming back. it's almost 4 weeks that i feel way too sick to work seriously on wget. i am very sorry. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi University of Ferrara - Dept. of Eng.http://www.ing.unife.it Institute of Human Machine Cognition http://www.ihmc.us Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
E-Mail distribution
Hello WGET Team, I'm in your e-mail distribution list, please please delete me at this list because I´ve got so much mails with viruses and in my company they become crazy Please let me know about the deleting. Thank you very much Greetings Philipp
