BSD getopt bugs

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I found a regression in m4 on cygwin 1.7, and traced it to the fact that
getopt.m4 no longer rejects BSD getopt even though it still has bugs
compared to GNU getopt_long.

Cygwin 1.7 is currently using getopt.c with the following header:
/*      $OpenBSD: getopt_long.c,v 1.23 2007/10/31 12:34:57 chl Exp $    */
/*      $NetBSD: getopt_long.c,v 1.15 2002/01/31 22:43:40 tv Exp $      */

This version of getopt.c has support for optind=0 implying a reset.
However, it is buggy, in that POSIXLY_CORRECT is queried exactly once;
whereas in GNU, optind=0 is a sign that POSIXLY_CORRECT must be re-queried
from the environment.  So, in applications (such as test-getopt) that call
getopt_long, then change the environment, then call getopt_long again, the
state of whether POSIX behavior will be used is erroneously locked down to
the prior behavior.

The second is that when POSIXLY_CORRECT is set, but the option string
begins with '-', BSD erroneously stops parsing at the first non-option,
rather than treating all non-options as arguments to option '\1'.  For
comparison, a build of m4 with gnulib getopt does:

$ touch a
$ m4 -d a -d
$ POSIXLY_CORRECT= m4 -d a -d
$

But with BSD getopt:

$ touch a
$ m4 -d a -d
$ POSIXLY_CORRECT= m4 -d a -d
m4: cannot open `-d': No such file or directory
$

In other words, BSD no longer realizes that -d is still an option.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksP/T4ACgkQ84KuGfSFAYDaXACeOTWTJv6M/yP639BJw8lZfpov
z4YAoM+u4AxX7NWvMQ5w0DGthZKiXqb8
=gqFA
-----END PGP SIGNATURE-----