[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: getopt() and POSIX
From: |
Elad Lahav |
Subject: |
Re: getopt() and POSIX |
Date: |
Tue, 16 May 2023 22:02:16 -0400 |
On Tue, May 16, 2023 at 9:54 PM Elad Lahav <e2lahav@gmail.com> wrote:
>
> Thanks, I did that following Eli's response. It was acknowledged as a
> bug (or at list the GNU C library deviating from POSIX) and that the
> QNX behaviour should be accepted as (also) correct.
I type faster than I think... At least. D'oh.
>
> --Elad
>
> On Tue, May 16, 2023 at 9:15 PM Po Lu <luangruo@yahoo.com> wrote:
> >
> > Elad Lahav <e2lahav@gmail.com> writes:
> >
> > > Hello,
> > >
> > > The configure script attempts to determines whether getopt() is POSIX
> > > compliant by compiling and running the following code:
> > >
> > > #include <unistd.h>
> > > #include <stdlib.h>
> > > #include <string.h>
> > >
> > > int
> > > main ()
> > > {
> > > static char program[] = "program";
> > > static char ab[] = "-ab";
> > > char *argv[3] = { program, ab, NULL };
> > > if (getopt (2, argv, "ab:") != 'a')
> > > return 13;
> > > if (getopt (2, argv, "ab:") != '?')
> > > return 14;
> > > if (optopt != 'b')
> > > return 15;
> > > if (optind != 2)
> > > return 16;
> > > return 0;
> > > }
> > >
> > > This test fails on QNX for the last test point, which has optind set
> > > to 3. However, as far as I can tell, this is what POSIX expects, and 2
> > > is wrong:
> > >
> > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/getopt.html
> > >
> > > "If the option was the last character in the string pointed to by an
> > > element of argv, then optarg shall contain the next element of argv,
> > > and optind shall be incremented by 2. If the resulting value of optind
> > > is greater than argc, this indicates a missing option-argument, and
> > > getopt() shall return an error indication."
> > >
> > > In this case optind is 1 and incremented by 2, the argument is missing
> > > and now optind is greater than argc (2), as expected.
> > >
> > > None of this really matters much, except that the compliance failure
> > > leads to an attempt to use rpl_getopt(), which fails due to unresolved
> > > symbols (which is a separate issue).
> >
> > Please bring this to the attention of the Gnulib developers (from whom
> > we get these tests), at bug-gnulib@gnu.org.
> >
> > Thanks.