X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com From: Eric Blake Subject: getopt bugs Date: Mon, 30 Nov 2009 16:54:31 +0000 (UTC) Lines: 52 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Cygwin 1.7 getopt has made some strides towards being more Linux-compatible, but there are still a couple remaining bugs recently detected by the m4 testsuite. On Linux, setting optind=0 forces a re-evaluation of getenv("POSIXLY_CORRECT"); this can be useful if a program wants to parse multiple argv sequences, and calls either unsetenv("POSIXLY_CORRECT") or setenv("POSIXLY_CORRECT","",1) in between the two sequences. But on cygwin, the environment is consulted only once and cached; thereafter, there is no way to change the state of whether the getopt engine will attempt posix compliance. On Linux, there is an extension to POSIX of using "-" at the beginning of the optstring argument to getopt to get it to parse all arguments in order until an instance of "--" is encountered (with non-options appearing as if they were the optarg of the invisible short-opt '\1'). Cygwin's getopt also supports this extension, but only when POSIXLY_CORRECT is unset (and given the first bug, there is no way to unset the POSIXLY_CORRECT state once getopt() has been invoked at least once). Since a leading dash in the optstring is a pure extension permitted by POSIX, the state of POSIXLY_CORRECT should not disable the extension. Here's an example of how the m4 testsuite caught this second bug (by the way, m4 is one of the few exceptions explicitly mentioned in POSIX where options must be parsed interspersed with file names, rather than the normal rule that options stop on the first non-option): On Linux or cygwin 1.5 (where there were enough other getopt bugs that m4 used the glibc getopt): $ echo foo > bar $ m4 -Dfoo=1 bar -Dfoo=2 bar 1 2 $ POSIXLY_CORRECT= m4 -Dfoo=1 bar -Dfoo=2 bar 1 2 On cygwin 1.7 (where m4 tried to use cygwin's native getopt) $ echo foo > bar $ m4 -Dfoo=1 bar -Dfoo=2 bar 1 2 $ POSIXLY_CORRECT= m4 -Dfoo=1 bar -Dfoo=2 bar m4: cannot open `-Dfoo=2': No such file or directory I don't know if either of these bugs have been fixed in the upstream BSD sources that cygwin borrowed from, or if we also need to raise a BSD bug report. But it does seem rather ironic that setting POSIXLY_CORRECT actually breaks POSIX compliance of m4 argument parsing. -- Eric Blake -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple