Re: Discrepancy in regards to program_name output

[Eric Blake]

On Wed, Jun 09, 2021 at 06:46:45PM +0200, Sören Tempel wrote:
> Hello,
> 
> I was debugging m4 test failures in an Alpine Linux Edge RISC-V RV64
> chroot emulated using qemu-user. The test failures looked as follows:
> 
>       checks$ ./check-them -I ../examples/ 021.macro_argu
>       -/usr/bin/m4:stdin:1: Warning: too few arguments to builtin `index'
>       -/usr/bin/m4:stdin:3: Warning: excess arguments to builtin `index' 
> ignored
>       +m4:stdin:1: Warning: too few arguments to builtin `index'
>       +m4:stdin:3: Warning: excess arguments to builtin `index' ignored
> 
> As one can see, the problem here is that the program name in the output
> differs. Once the full path is used and once it only uses the base name.

Thanks for the report.  We have also encountered the issue when
building m4 for Windows:
https://lists.gnu.org/archive/html/bug-m4/2021-05/msg00019.html

>
> As it turns, out this is due a discrepancy in regards to the handling of
> argv[0] in the m4 soure code. The check-them script attempts to
> determine how m4 prints argv[0] using the following code:
> 
>       # Find out how the executable prints argv[0]
>       m4name=`"$m4" --help | ${SED} -e 's/Usage: \(.*\) \[OPTION.*/\1/' \
>               -e 's/\\\\/\\\\\\\\/g' -e 1q`
> 
> That is, it extracts argv[0] from the usage string in the --help output.
> This argv[0] value is then added to the expected output. This usage
> string is generated using the following code from src/m4.c:
> 
>       xprintf ("Usage: %s [OPTION]... [FILE]...\n", program_name);
> 
> In this case, program_name is defined by the m4 header file progname.h
> which is included in src/m4.c and set using set_program_name from
> lib/progname.c based on argv[0] as passed to main().
> 
> Unfortunately, the error messages generated by m4 (e.g. `Warning: too
> few arguments to builtin `index'` from above) use a different technique
> to determine the program name. The output of error messages can be
> traced to the file lib/error.c (which seems to have been copied from the
> glibc source code). The lib/error.c file adds the program name to the

Rather, imported from gnulib, but gnulib tends to stay close to glibc.

> error output. However, since it has been copied from glibc it does not
> use the m4-specific progname.h. Instead, it has a it's own ifdef jungle
> to determine a technique for extracting the program name. On my system,
> it ultimately uses program_invocation_short_name via lib/getprogname.c.
> Since program_invocation_short_name is set by the libc, it can differ
> from the program_name value as used in the usage string. In fact,
> program_invocation_short_name is the basename of argv[0], thereby
> causing it to differ from the value extracted from the --help output.
> 
> tl;dr If argv[0] is a full path (e.g. because of qemu-user usage),
> many tests will fail because --help uses argv[0] while error messages
> use basename(argv[0]).
> 
> Not sure how to resolve this, if getprogname is expected to return
> basename(argv[0]) the following comment in lib/progname.c is incorrect,
> since getprogname, not lib/program.c is used for error messages:
> 
>       /** But don't strip off a leading <dirname>/ in general, because when 
> the user runs
>             /some/hidden/place/bin/cp foo foo
>           he should get the error message
>             /some/hidden/place/bin/cp: `foo' and `foo' are the same file
>           not
>             cp: `foo' and `foo' are the same file
>       */

Bruno's suggestion for fixing things on Windows should also fix your
use case; I'm planning on improving the program name substitution in
checks/check-them to filter out any absolute name in argv[0]; while it
is still desirable in the common case (per the comment you quoted) for
output to include a full path name when available, it is unpredictable
enough (whether because of native Windows always passing an absolute
path name in even when invoked by a relative name, or due to argv[0]
rewriting when executing via qemu in your situation, or ...) that
having the test just focus on basenames is going to be more reliable.

We've got enough other issues reported with m4 1.4.19 that I will be
releasing 1.4.20 sometime this summer, and this issue will be one of
the things fixed by that release.

> 
> I am not subscribed to the list, please CC me.

Yes, it's list policy to reply-all.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org