Re: getopt() and POSIX

[Bruno Haible]

Hi Elad,

Elad Lahav wrote:
> 
> The configure script attempts to determine 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.

I agree with you: POSIX [1][2] wants optind to be 3 in this case, whereas
the traditional behaviour (glibc, BSD, Solaris, Cygwin) is that optind is 2.
Also, musl libc (which is known for being very standards compliant in
general) behaves like POSIX says, i.e. the configure test fails not only
on QNX, but also on musl libc.

The motivation for the traditional behaviour is possibly that it easily
leads to overrun bugs if optind > argc ?

It appears that when we added this test to gnulib [3][4], we made a
mistake by classifying it as a "MacOS bug". Because at that time POSIX [1]
already contained the wording that you cite.

I'll prepare a fix for the 'getopt-posix' module. However, for the
'getopt-gnu' module we'll still want to have the same behaviour in
Gnulib as in glibc.

> (The following was reported on emacs-devel, but I was told to post it
> here instead. Perhaps they just want me to go away...)

Here I need to give you a real-life advice. When someone communicates
with you, you should generally assume that they act in good faith, that
is, that they honestly mean what they say and that they have no goals
that they are hiding from you. Each time you assume someone is acting
in bad faith, but they are actually acting in good faith, you are
damaging or destroying your relation between that person and yourself.

Eli's answer to you [5] was perfectly honest and adequate. You have no
reason to claim that he "just wanted you to go away".

Bruno

[1] https://pubs.opengroup.org/onlinepubs/009695399/functions/getopt.html
[2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/getopt.html
[3] 
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=5cc0bcf5e4689e1fb0c23b8368c46fdae0402028
[4] https://lists.gnu.org/archive/html/bug-gnulib/2010-04/msg00272.html
[5] https://lists.gnu.org/archive/html/emacs-devel/2023-05/msg00404.html