Discrepancy in regards to program_name output

[Sören Tempel]

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.

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

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

Greetings,
Sören