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

[Bruno Haible]

Paul Eggert wrote:
> While we're on the subject of getopt, it's long bothered me that GNU
> getopt lies to the compiler about whether its argv parameter is a
> pointer to a const.  This leads to undefined behavior, according to
> C99.

Thanks for this patch, it should help against programming errors.
But this patch has two drawbacks:

1) It leads to warnings or errors on non-glibc platforms only, whereas
most people develop and test on glibc platforms. This is opposite to the
goal of gnulib.

2) There are cases where the programmer knows in advance that he is
right in passing a 'char * const *', yet with the new signature the
compiler will give a warning (gcc with -Wall) or an error (IRIX cc
or a C++ compiler).

Here's an example for both problems:

==========================================================================
int glibc_getopt (int argc, char * const * argv, const char *options);
int gnulib_getopt (int argc, char ** argv, const char *options);

int main_without_const (int argc, char* argv[]) {
  glibc_getopt(argc, argv, "+x");
  gnulib_getopt(argc, argv, "+x");
  return 0;
}

int main_with_const (int argc, char* argv[]) {
  glibc_getopt(argc, (char* const*) argv, "+x");
  gnulib_getopt(argc, (char* const*) argv, "+x"); // WARNING, in C++ ERROR
  return 0;
}
===========================================================================

Any ideas?

Can we detect whether the first character of the options string is a '+'
through a ___builtin_constant_p call and use a function with appropriate
prototype?

Is getopt() worth fiddling with at all? Most GNU programs use getopt_long,
which doesn't have a semantics dictated by POSIX.

Bruno