Re: getopt.m4 test

[Bruno Haible]

Rich Felker wrote:
> > > 3. The test for "POSIX compatible" getopt does not actually test for
> > > POSIX compatibility, but for GNU semantics which are contrary to
> > > POSIX. This is purely an issue of a misnamed test; if gnulib wants to
> > > provide a replacement getopt with GNU semantics, that's okay, but it
> > > should not tell the user that the host getopt is not "POSIX
> > > compatible".

Eric Blake replied:
> > We've already separated the getopt module into tests for POSIX behavior
> > vs. tests for GNU extension behavior.  Which particular aspect are you
> > claiming is incorrectly attributed to POSIX behavior when it should be
> > treated as GNU behavior instead?  And is this occurring when the
> > getopt-gnu module is in use, or is it reproducible when using just the
> > getopt-posix module?  Or is this just a case of inaccurate wording but
> > accurate testing?

In config.log I'm seeing that the test program is compiled with -DOPTIND_MIN=0
and then fails with exit code 1.

Here are the details:
================================ foo.c ================================
#include <unistd.h>
#include <stdlib.h>
#include <string.h>

int
main ()
{
  {
    static char program[] = "program";
    static char a[] = "-a";
    static char foo[] = "foo";
    static char bar[] = "bar";
    char *argv[] = { program, a, foo, bar, NULL };
    int c;
#ifdef OPTIND_MIN
    optind = OPTIND_MIN;
    opterr = 0;
#endif
    c = getopt (4, argv, "ab");
    if (!(c == 'a'))
      return 1;
    c = getopt (4, argv, "ab");
    if (!(c == -1))
      return 2;
    if (!(optind == 2))
      return 3;
  }
  return 0;
}
=======================================================================

$ musl-gcc foo.c -Wall; ./a.out; echo $?
0
$ musl-gcc foo.c -Wall -DOPTIND_MIN=0; ./a.out; echo $?
1
$ musl-gcc foo.c -Wall -DOPTIND_MIN=1; ./a.out; echo $?
0

So, musl's getopt works right when 'optind' is not initialized by the
program, or when it is initialized to 1. Like for BSD systems, but BSD
systems have 'optreset' for resetting the option processing.

It seems to me that
  - musl's getopt is POSIX compliant (at least it passes the 3 parts of
    the test when run individually).
  - The getopt.m4 test fails only because musl does not support one of
    the 3 known ways to reset option processing. Does it support another
    method, or none at all?
  - coreutils does not rely on resetting option processing with getopt(),
    only with getopt_long() (in coreutils/src/{env.c,nice.c,stty.c}).
  - The use of OPTIND_MIN in getopt.m4 exists purely to run a single
    test program rather than 3 test programs in sequence.

Paul, I would suggest to split out the 3 tests into a sequence of 3 test
programs, and then remove the determination of gl_optind_min - since
nothing else uses it.

Rich Felker wrote:
> I was testing with GNU m4. The test that fails has non-option
> arguments placed before options, and tests to see if it can get the
> option with getopt.

As far as I can see, "checking whether getopt is POSIX compatible"
does not check this; it's the "checking for working GNU getopt function"
part which does it (look for the comment
"This code succeeds on glibc 2.8 and fails on Cygwin 1.7.0.").

Bruno