[Bug-wget] alpha release (1.13.4.56-620c) (was: [PATCH] gnutls.c: fix infinite read timeout)

[Steven M. Schweda]

> ftp://alpha.gnu.org/gnu/wget/wget-1.13.4.56-620c.tar.bz2

> Please test it and let me know of any problem.

   This problem on Tru64 UNIX is still unsolved:

      http://lists.gnu.org/archive/html/bug-wget/2012-04/msg00050.html


   This problem on VMS is still unsolved:

ALP $ gdiff -du src/connect.c_orig src/connect.c
--- src/connect.c_orig  2012-05-12 10:18:27 -0500
+++ src/connect.c       2012-05-22 07:59:19 -0500
@@ -36,8 +36,13 @@
 #include <unistd.h>
 #include <assert.h>

-#include <sys/socket.h>
-#include <sys/select.h>
+#ifdef HAVE_SYS_SOCKET_H
+# include <sys/socket.h>
+#endif /* def HAVE_SYS_SOCKET_H */
+
+#ifdef HAVE_SYS_SELECT_H
+# include <sys/select.h>
+#endif /* def HAVE_SYS_SELECT_H */

 #ifndef WINDOWS
 # ifdef __VMS

   I don't have anything like <sys/select.h>, and adding a dummy
replacement would be annoying, because I also don't have a "sys"
directory.  What's the point of defining the macros HAVE_SYS_SELECT_H
and HAVE_SYS_SOCKET_H in src/config.h, and then not using them where
appropriate?  (When asked for <sys/xxx.h>, the DEC/Compaq/HP compiler
will look for <xxx.h> in its usual places, so "#include <sys/socket.h>"
actually works (using <socket.h>), but this will fail if I create a new
"sys" directory for <sys/select.h>.  There may be some complex and ugly
work-around for this, bit it's simpler and cleaner to use the existing
macros.  Which is why they exist, isn't it?)


   There's a new problem on systems (like VMS) where size_t is unsigned:

--- src/warc.c_orig     2012-05-18 04:28:46 -0500
+++ src/warc.c  2012-05-22 08:36:28 -0500
@@ -938,7 +938,7 @@
      need 'a' (the original url), 'k' (the SHA1 checksum) and
      'u' (the WARC record id). */
   line_length = getline (&lineptr, &n, f);
-  if (line_length != -1)
+  if (line_length != (size_t)-1)
     warc_parse_cdx_header (lineptr, &field_num_original_url,
                            &field_num_checksum, &field_num_record_id);
 
@@ -966,14 +966,14 @@
       do
         {
           line_length = getline (&lineptr, &n, f);
-          if (line_length != -1)
+          if (line_length != (size_t)-1)
             {
               warc_process_cdx_line (lineptr, field_num_original_url,
                             field_num_checksum, field_num_record_id);
             }
 
         }
-      while (line_length != -1);
+      while (line_length != (size_t)-1);
 
       /* Print results. */
       int nrecords = hash_table_count (warc_cdx_dedup_table);


   There's another portability problem in src/warc.c:

           redirect_location, offset, warc_current_filename, response_uuid);
..............................^
%CC-W-OUTTYPELEN, In this statement, this argument to fprintf is of "a signed in
teger 64" type and is not appropriate for the conversion specifier "%ld".  The v
alue might be truncated or formatted in an unintended manner.
at line number 1232 in file ALP$DKC0:[UTILITY.SOURCE.WGET.wget-1_13_4_56-620c.sr
c]warc.c;2

   Around here, "file offset is 64 bits" and "long is 64 bits" are not
equivalent, so "%ld" is not appropriate when large-file support is
enabled.  (And "%lld" is no good when large-file support is _not_
enabled, as on VAX (or very old Alpha) systems.)  I haven't looked
carefully to see if you already have a way to handle printing an off_t. 
I did see some "xxx_T_SUFFIX" macros, but not one for this case.


   It's not really your fault, but the GNU regex code (lib/regcomp.c)
has an annoying portability problem, because what could easily have been
a compile-time decision was postponed until run-time.  A good compiler
complains about loss of significant bits when BITSET_WORD_BITS < 64:

      if (BITSET_WORD_BITS == 64)
        {
          dfa->word_char[0] = UINT64_C (0x03ff000000000000);
          dfa->word_char[1] = UINT64_C (0x07fffffe87fffffe);

Not fatal, however, only annoying.  (And, I claim, stupid.  And
relatively easy to fix, unless you _really_ like it the way it is, which
seems to be the case for the GNU regex maintainer.)


   I assume that I'll find more problems as I try to get the new code
into the VMS builders, but those are the ones which popped up first.

------------------------------------------------------------------------

   Steven M. Schweda               address@hidden
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547