bug-wget
[Top][All Lists]
Advanced

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

Re: [Bug-wget] Wget 1.12 v. VMS


From: Micah Cowan
Subject: Re: [Bug-wget] Wget 1.12 v. VMS
Date: Thu, 24 Sep 2009 12:46:29 -0700
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Comments inline.

Steven M. Schweda wrote:
>    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.

Good point. :)

Applied.

>    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. */

Applied.

> 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.)

"Not universally available"? It's part of the C standard, since 1989.
And it surely must exist on your platform, since if that #if clause is
firing, then so is the one in snprintf.c, whose snprintf implementation
uses vsnprintf (and therefore va_list), and apparently doesn't fail to
compile.

I'll fix both (the va_list will require <stdarg.h> as well). Using a
non-prototype function declaration to refer to a function that uses
variable parameters is expressly forbidden by the C standard (though I
suppose that would only apply to snprintf).

But we should move this stuff over to gnulib anyway, where they actively
maintain their snprintf implementation. For now, this will do.

>    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.

Actually, it looks like this is the type cast doing its job: according
to comments in gettext.h, the cast is to prevent callers from trying to
use gettext's return value inappropriately. host_errstr() should have
been returning a const char*, which would make this message go away.
I've fixed host_errstr()'s return type.

>    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/".

I made these changes in the repo.

>   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.

Is vms/getopt.h just copied from lib/getopt.in.h? I assumed it was, and
made this change.

>    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.)

Cool. :)

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
Maintainer of GNU Wget and GNU Teseq
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkq7zJQACgkQ7M8hyUobTrGEPQCeLzigrSIEaIQljanJPtqzmDje
GfsAoI8UFOSAhjQGLlLkA/Y3c01JnOn9
=IATT
-----END PGP SIGNATURE-----





reply via email to

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