This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] manual: Document optind zero set behaviour (BZ#23157)
On 29/05/2018 17:02, Carlos O'Donell wrote:
> On 05/29/2018 02:44 PM, Adhemerval Zanella wrote:
>> Now I am not sure if program is abusing of getopt semantic, or glibc is tying
>> with information it should (the input argument), or if it just undefined
>> behaviour.
>
> We have no test cases that use optind setting to zero. That isn't proof conclusive
> that the feature is not supported.
We do:
* posix/bug-getopt2.c explicit sets optind first to 0 and then to 1.
* posix/tst-getopt-cancel.c also sets optind to 0.
Both are due to explicit reset internal state to handle the optstring starting
with '+'.
>
> We have only a manual page with a note about resetting optind to 0 to allow the
> reset to happen. That's not canonical.
>
> We have a BSD implementation that does something similar but with a distinct
> variable.
>
> My suggestion:
>
> * Review other implementations of GNU getopt and see what they support for
> optind setting to 0, e.g. https://github.com/agriffis/pure-getopt
> If they don't support setting optind to 0, then that's better proof that
> we should not support this.
I don't think this example applies here (optind is really tied to C semantic,
this bash project have a different to access the results). GLIBC getopt is
pretty much in sync with gnulib and I am not aware of any other gnu getopt
replacement.
>
> * Consider copying BSD's non-standard optreset. I like the idea of a distinct
> variable for use in the reset.
I am not sure because we will have different reset mechanism if we want to
provide the current semantic and we will need to define optreset interaction
with GNU extensions (which is essentially which adds optind complexity here).
We can also rewrite how optind interacts with GNU extensions and define optreset
would be canonical way, but it will also adds more code complexity and probably
requires a compat symbol.
>
> * Consider sending a patch to the linux man pages project to remove the
> note regarding glibc's undocumented method for rescanning.
I still prefer if we document more properly what are GLIBC behaviour regarding
non specified POSIX semantic.