From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6585 Path: news.gmane.org!not-for-mail From: Felix Janda Newsgroups: gmane.linux.lib.musl.general Subject: Re: More GNU semantics for getopt_long? Date: Fri, 21 Nov 2014 19:49:55 +0100 Message-ID: <20141121184955.GA2284@euler> References: <20140726091236.GA6011@euler> <20140726093140.GM4038@brightrain.aerifal.cx> <20140726174730.GA11205@euler> <20140727183546.GC4038@brightrain.aerifal.cx> <20140727223044.GA10396@euler> <20141119174227.GL22465@brightrain.aerifal.cx> <20141119184449.GA1608@euler> <20141119225044.GP22465@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1416595861 11057 80.91.229.3 (21 Nov 2014 18:51:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Nov 2014 18:51:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6598-gllmg-musl=m.gmane.org@lists.openwall.com Fri Nov 21 19:50:53 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XrtI6-0007zh-TZ for gllmg-musl@m.gmane.org; Fri, 21 Nov 2014 19:50:47 +0100 Original-Received: (qmail 20301 invoked by uid 550); 21 Nov 2014 18:50:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 20289 invoked from network); 21 Nov 2014 18:50:45 -0000 X-Virus-Scanned: amavisd-new at posteo.de Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20141119225044.GP22465@brightrain.aerifal.cx> User-Agent: Mutt/1.5.22 (2013-10-16) Xref: news.gmane.org gmane.linux.lib.musl.general:6585 Archived-At: Rich Felker wrote: > > > > I also noticed that 66fcde4ae4a52ae3edb1cf237ce2c22d08d7a062 seems > > > > to have broken getopt_long: Even if optstring does not begin with > > > > ':', getopt_long will return ':' if a long option is not supplied > > > > by its required argument. > > > > > > Is this still broken, and if so, could you provide a short testcase I > > > could use for checking it and figuring out what's wrong? > > > > Nothing has changed. Below is a testcase. > > > > --Felix > > > > #include > > #include > > > > int main(void) { > > struct option opts[2] = {{"opt", 1, NULL, 'o'}, {0, 0, 0, 0}}; > > int ret; > > > > ret = getopt_long(2, (char *[3]){"a", "--opt", 0}, "", opts, NULL); > > if (ret != '?') printf("'%d' != '%d'\n", ret, '?'); > > > > return 0; > > } > > Are you sure it's related to the change in that commit? I think it was > always this way. getopt_long.c seems to return ':' unconditionally > when the argument is missing rather than returning '?'. Right, it doesn't seem to be related to the commit. > We probably > also need to look into what the appropriate behavior should be for how > the parsing state is left when errors like this are encountered, > although I would guess optind should just end up pointing to the null > pointer at the end of argv so that subsequent calls report that > they're at the end. The POSIX page on getopt confuses me a bit. It says: The getopt() function shall return the next option character (if one is found) from argv that matches a character in optstring, if there is one that matches. If the option takes an argument, getopt() shall set the variable optarg to point to the option-argument as follows: 1. If the option was the last character in the string pointed to by an element of argv, then optarg shall contain the next element of argv, and optind shall be incremented by 2. If the resulting value of optind is greater than argc, this indicates a missing option-argument, and getopt() shall return an error indication. So should optind be increased by 2 to point into nirvana when the argument is missing? Considering the Example below on the page, I think that it rather should behave as you have described. Felix