Re: [Bug-wget] Wget 1.13.4 v. VMS -- Various problems

[Steven M. Schweda]

From: Micah Cowan <address@hidden>

> On 09/28/2011 06:39 AM, Steven M. Schweda wrote:
> > From: Micah Cowan<address@hidden>
> >> In this case, the logic that does a rename of snprintf seems to be at
> >> the end of "vasnprintf.h" rather than directly in snprintf.c.
> > 
> >     Those aren't the droids you're looking for.  Try "lib/stdio.in.h"
> > (which I also try very hard to ignore).
> 
> Yes, but lib/stdio.in.h isn't included directly by snprintf.c, as
> vasnprintf.h is. The bit I'm talking about is indeed in vasnprintf.h,
> which is what actually does the rename of the link name.

   What, exactly, do you see where, exactly?  All I see in
"lib/vasnprintf.h" is stuff like:
      # define vasnprintf rpl_vasnprintf
      # define asnprintf rpl_asnprintf
and neither "vasnprintf" nor "asnprintf" looks quite like "snprintf" to
me.  But what do I know?

   On the ACCVIO front, the first problem seems to occur with any short
option on the command line.  My sophisticated diagnostics (fprintf())
suggest that there may be a problem in the command-line parsing in
"src/main.c:main()".  This seems to be the bad section (worse than just
the spelling of "separate"):

[...]
  /* This seperate getopt_long is needed to find the user config
     and parse it before the other user options. */
  longindex = -1;
  int retconf;
  bool use_userconfig = false;

/* SMSd. */
fprintf( stderr, " Pre-getopt_long(1) loop.  argc = %d, longindex = %d.\n",
 argc, longindex);

  while ((retconf = getopt_long (argc, argv,
                                short_options, long_options, &longindex)) != -1)
    {
      int confval;
      bool userrc_ret = true;
      struct cmdline_option *config_opt;

/* SMSd. */
fprintf( stderr, "    getopt_long(1) loop.  longindex = %d, retconf = %d.\n",
 longindex, retconf);

      confval = long_options[longindex].val;

/* SMSd. */
fprintf( stderr, "    getopt_long(1) loop.  confval = %d.\n", confval);
[...]

With only a long option, I get output like the following:

ALP $ wgx --hel
 Pre-getopt_long(1) loop.  argc = 2, longindex = -1.
    getopt_long(1) loop.  longindex = 68, retconf = 47.
    getopt_long(1) loop.  confval = 47.
GNU Wget 1.13.4a, a non-interactive network retriever.
[...]


With a short option, I get output like the following:

ALP $ wgx -h
 Pre-getopt_long(1) loop.  argc = 2, longindex = -1.
    getopt_long(1) loop.  longindex = -1, retconf = 104.
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000028
FFFC, PC=00000000000E0E90, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
  image    module    routine             line      rel PC           abs PC
 WGET  MAIN  no_prefix                  24135 0000000000000E90 00000000000E0E90
 WGET  MAIN                             23537 00000000000E0E90 0000000000000000
 WGET  MAIN  __main                     24076 0000000000000A1C 00000000000E0A1C
 WGET                                       0 00000000002839E0 00000000002839E0
                                            0 FFFFFFFF8037FCE4 FFFFFFFF8037FCE4
%TRACE-I-END, end of TRACE stack dump

   Listing line 24135 is:

      2   24135       confval = long_options[longindex].val;

Apparently, referencing "long_options[-1]" causes more trouble in a VMS
environment than it does on a typical UNIX(-like) system.  It worked on
a Tru64 system, for example:

urtx# src/wget -h
 Pre-getopt_long(1) loop.  argc = 2, longindex = -1.
    getopt_long(1) loop.  longindex = -1, retconf = 104.
    getopt_long(1) loop.  confval = 0.
GNU Wget 1.13.4, a non-interactive network retriever.
[...]

But "longindex" is still -1 in this case, and this seems to me to be a
risky thing to use as a subscript in "long_options[]".  (But I'm always
open to a good counter-argument.)

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

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