From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6573 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: More GNU semantics for getopt_long? Date: Wed, 19 Nov 2014 17:50:44 -0500 Message-ID: <20141119225044.GP22465@brightrain.aerifal.cx> 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> 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 1416437469 28058 80.91.229.3 (19 Nov 2014 22:51:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Nov 2014 22:51:09 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6586-gllmg-musl=m.gmane.org@lists.openwall.com Wed Nov 19 23:51:00 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 1XrE5T-0002R1-6I for gllmg-musl@m.gmane.org; Wed, 19 Nov 2014 23:50:59 +0100 Original-Received: (qmail 22508 invoked by uid 550); 19 Nov 2014 22:50:57 -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 22494 invoked from network); 19 Nov 2014 22:50:56 -0000 Content-Disposition: inline In-Reply-To: <20141119184449.GA1608@euler> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6573 Archived-At: On Wed, Nov 19, 2014 at 07:44:50PM +0100, Felix Janda wrote: > Rich Felker wrote: > > I'd like to resume working on getting this integrated, especially > > since one of the main Roadmap goals for 1.1.6 is solving the remaining > > issues Alpine Linux is matching musl for, of which getopt_long is one. > > Thanks for coming back to this. > > > > 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 '?'. 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. Rich