Re: [Bug-gnulib] getopt fix to prevent it from lying to the compiler about const

[Bruno Haible]

Paul Eggert wrote:
> One simple solution would be to have different interfaces for the two
> getopt cases.  E.g.:
> 
> int getopt (int, char * const *, char const *);
> int getopt_long (int, char * const *, char const *,
>                struct option const *, int *);
> int getopt_long_only (int, char * const *, char const *,
>                       struct option const *, int *);
> 
> int getopt_permute (int, char **, char const *);
> int getopt_long_permute (int, char **, char const *
>                        struct option const *, int *);
> int getopt_long_only_permute (int, char **, char const *,
>                               struct option const *, int *);

Separating getopt into getopt and getopt_permute (or getopt_reorder)
indeed looks like the cleanest solution. In parallel with this split,
getopt() would become POSIX compliant again, regardless of environment
variables.

I don't see the need for getopt_long_permute and getopt_long_only_permute:
GNU "owns" these interfaces; therefore you can use 'char **' in gnulib
and hopefully also soon in libc.

In order to manage compatility with glibc, the getopt.m4 macro should do
the following:
  - On glibc systems, AC_DEFINE([getopt_permute], [getopt])
  - On other systems, tell the Makefile to copy getopt_.h to getopt.h,
    like it already does.

> other programs (the majority of them) can call getopt_permute etc.

Yes, even if it's the majority, it's worth the change.

The only remaining problem with this solution would be that on non-glibc
systems, programs that are not yet adapted (i.e. which call getopt(),
not getopt_permute()) will get a POSIX compliant getopt(), which handles
"--" in an inferior way.

Bruno