[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-wget] Wget 1.13.4 v. VMS -- Various problems
From: |
Steven M. Schweda |
Subject: |
Re: [Bug-wget] Wget 1.13.4 v. VMS -- Various problems |
Date: |
Wed, 28 Sep 2011 22:18:20 -0500 (CDT) |
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
- [Bug-wget] Wget 1.13.4 v. VMS -- Various problems, Steven M. Schweda, 2011/09/28
- Re: [Bug-wget] Wget 1.13.4 v. VMS -- Various problems, Steven M. Schweda, 2011/09/28
- Re: [Bug-wget] Wget 1.13.4 v. VMS -- Various problems,
Steven M. Schweda <=
- Re: [Bug-wget] Wget 1.13.4 v. VMS -- Various problems, Steven M. Schweda, 2011/09/29
- Re: [Bug-wget] Wget 1.13.4 v. VMS -- Various problems, Steven M. Schweda, 2011/09/29
- Re: [Bug-wget] Wget 1.13.4 v. VMS -- Various problems, Steven M. Schweda, 2011/09/29
- Re: [Bug-wget] Wget 1.13.4 v. VMS -- Various problems, Steven M. Schweda, 2011/09/30
- Re: [Bug-wget] Wget 1.13.4 v. VMS -- Various problems, Steven M. Schweda, 2011/09/30