From: Micah Cowan <mi...@cowan.name> > On 09/28/2011 06:39 AM, Steven M. Schweda wrote: > > From: Micah Cowan<mi...@cowan.name> > >> 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 sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547