bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-wget] Wget 1.12 v. VMS


From: Steven M. Schweda
Subject: [Bug-wget] Wget 1.12 v. VMS
Date: Thu, 24 Sep 2009 09:54:50 -0500 (CDT)

   Today's mostly-VMS-related whining complaints, suggestions, and
questions, based on the official 1.12 source kit:

   1.  Slip-up in "src/ftp.c"?:

ALP $ gdiff -u ftp.c_orig ftp.c
--- ftp.c_orig  2009-09-21 21:59:21 -0500
+++ ftp.c       2009-09-23 09:19:12 -0500
@@ -690,7 +690,7 @@
           if (!opt.server_response)
             logprintf (LOG_VERBOSE, "==> CWD (%d) %s ... ", cwd_count,
                        quotearg_style (escape_quoting_style, target));
-          err = ftp_cwd (csock, target);
+          err = ftp_cwd (csock, targ);
           /* FTPRERR, WRITEFAILED, FTPNSFOD */
           switch (err)
             {

There's not much point in all that code setting "targ" if it's not
actually used.

   2.  Rip out the lame, forgotten-by-me OS_TYPE-substitute code from
"src/main.c".

ALP $ gdiff -u main.c_orig main.c
--- main.c_orig 2009-09-21 22:03:11 -0500
+++ main.c      2009-09-23 09:30:58 -0500
@@ -785,12 +785,7 @@
   char *env_wgetrc, *user_wgetrc;
   int i;

-#ifdef __VMS
-  printf (_("GNU Wget %s built on VMS %s %s.\n\n"),
-   version_string, vms_arch(), vms_vers());
-#else /* def __VMS */
   printf (_("GNU Wget %s built on %s.\n\n"), version_string, OS_TYPE);
-#endif /* def __VMS */
   /* compiled_features is a char*[]. We limit the characters per
      line to MAX_CHARS_PER_LINE and prefix each line with a constant
      number of spaces for proper alignment. */

The new VMS builders will set OS_TYPE appropriately.

   3.  On my VAX, using "Compaq C V6.4-005 on OpenVMS VAX V7.3"
(probably the last C compiler ever there), I get warnings from an
unrealistic function prototype in "src/sysdep.h":

        int snprintf (char *str, size_t count, const char *fmt, ...);
        ....^
%CC-W-FUNCREDECL, In this declaration, function types differ because one has no
 argument information and the other has an ellipsis.
                At line number 130 in SYS$SYSDEVICE:[UTILITY.SOURCE.WGET.WGET-1_
12.SRC]SNPRINTF.C;1.

Is there any reason not to have a realistic function prototype in
"src/sysdep.h" for this one?  For example:

ALP $ gdiff -u sysdep.h_orig sysdep.h
--- sysdep.h_orig       2009-09-04 11:31:54 -0500
+++ sysdep.h    2009-09-24 08:25:41 -0500
@@ -216,7 +216,7 @@
 /* These are defined in snprintf.c.  It would be nice to have an
    snprintf.h, though.  */
 #ifndef HAVE_SNPRINTF
-int snprintf ();
+int snprintf (char *str, size_t count, const char *fmt, ...);
 #endif
 #ifndef HAVE_VSNPRINTF
 int vsnprintf ();

(I didn't "improve" the vsnprintf() prototype, because it needs
"va_list", which not universally available.  A realistic snprintf()
seems to be harmless around here, however.)

   4.  That VAX C compiler is also dismayed by the "(const char *)"
type-cast in the dummy gettext() macro in "lib/gettext.h" and
"src/gettext.h".  For example:

            return _("Unknown host");
        ...........^
%CC-W-NOTCONSTQUAL, In this statement, the referenced type of the pointer value
 "((const char ...)("Unknown host"))" is const, but the referenced type of the
 target of this assignment is not.
                At line number 358 in SYS$SYSDEVICE:[UTILITY.SOURCE.WGET.WGET-1_
12.SRC]HOST.C;1.

I couldn't find a classy way around this, so I expect to need to disable
this warning in the compiler commands.  Sigh.

   5.  For the record, there's an interesting compiler quirk on non-VAX
systems (here, "HP C V7.3-009 on OpenVMS Alpha V7.3-2").  For example:

      CLEAR_CELL (c);
......^
%CC-I-INTCONSTTRUNC, In this statement, conversion of the constant "((void ...)~
(uintptr_t)0)" to pointer to void type will cause data loss.
at line number 466 in file ALP$DKA100:[UTILITY.SOURCE.WGET.wget-1_12.src]hash.c;
1

This seems to be caused by a system header file (inttypes.h) always
using "typedef uint64_t uintptr_t;" on non-VAX systems, even when 32-bit
pointers (the default) are being used.  The comment says, "Declare
[un]signed integral types large enough to hold any pointer.", but
there's no attempt to get an exact fit, and then the compiler complains
when it's not.  It's only an informational ("-I-") complaint, so the
builders don't care.  I'll try to remember to mention it in the
documentation, to reduce user anxiety.

   6.  To simplify the VMS builders, I'd like to move "vms/vms.c" to
"src/vms.c".  That would leave no ".c" files in "vms/".  There are some
old, VMS-specific header files in "vms/", and I'm adding some new ones:
an empty "alloca.h", and a "stdint.h" which includes <inttypes.h> (which
does exist on VMS).  These can/should stay in "vms/".

  7.  Using GNU autojive on VMS is impractical, so I'm still starting
with a hand-edited "vms/config.h_vms", but the new builders include a
DCL procedure to suck the AC_INIT strings out of "configure.ac", and
then append some suitable macros ("PACKAGE*", "VERSION") along with a
realistic "OS_TYPE" to the end of it, to make a plausible "config.h". 
On a good day, this would allow a version change without re-hand-editing
"vms/config.h_vms", if there's no significant change in any of the
configure-related stuff.  (If this is just a dream, then please don't
wake me.)

   8.  Note that all the generated/processed header files (currently
"getopt.in.h" -> "getopt.h" and "config.h_vms" -> "config.h") are placed
into architecture-specific product directories, so that the same source
tree can be used for building simultaneously on multiple hardware
architectures.

   So far, the builders seem to be working with MMS on VAX (V7.3) and
Alpha (V7.3-2), with ODS2 and ODS5 disks.  I need to try things on IA64,
and with MMK instead of MMS, and with no SSL, HP SSL, and OpenSSL, and
then on some older OS/compiler versions, but there seems to be some
hope.  (For 1.12.1 or something, anyway.)

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]