getopt() and POSIX

getopt() and POSIX

[Elad Lahav]

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).

Thoughts?

--Elad

Re: getopt() and POSIX

[Eli Zaretskii]

> From: Elad Lahav <e2lahav@gmail.com>
> Date: Tue, 16 May 2023 13:59:29 -0400
> 
> 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).

Both this test and rpl_getopt are imported from Gnulib, so please
report these 2 issues to bug-gnulib@gnu.org, so that Gnulib developers
could take care of what needs to be fixed.

Thanks.

Re: getopt() and POSIX

[Po Lu]

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.

Re: getopt() and POSIX

[Elad Lahav]

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.

--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.

Re: getopt() and POSIX

[Elad Lahav]

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.