-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Mikhail Teterin on 9/21/2006 6:43 AM: > On Thursday 21 September 2006 08:33, Eric Blake wrote: > = > getopt(c, v, "r::"); > = > = ...even though the "::" in this line is what makes this test program leave > = the realm of POSIX-specified behavior (and why GNU and BSD differ on > = opinion on what should happen). > > It would seem to me, that it is gm4, that should change to rely on > Posix-specified behavior of standard functions (like getopt) instead of > expecting the platform's getopt to be "extended" or building its own > replacement for the standard function(s).
Sorry, but GNU coding standards require that GNU programs use long options, and that is already something that POSIX-specified getopt() cannot do. Instead, gnulib makes it very easy, with getopt_long(), to meet both GNU coding standards and to attempt to provide a superset of POSIX semantics (and witness the various debates on the Austin mailing list for how POSIXLY_CORRECT plays into whether getopt/getopt_long are allowed to rearrange argument order). Optional arguments may not be encouraged by POSIX, but they are certainly allowed as an extension, and since -d is not a POSIX-required argument for m4, GNU m4 is not about to stop making -d take an optional argument just because the platform fails to provide getopt_long or provides a getopt_long that is not up to GNU standards. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFEorj84KuGfSFAYARAms3AKDP8JQtMRyo1WiKOyZD+/9QGZxb8QCfTwAU xngzJFxnUqLWITvY4vrpysI= =ihb7 -----END PGP SIGNATURE-----
