mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Felix Janda <felix.janda@posteo.de>
To: musl@lists.openwall.com
Subject: Re: More GNU semantics for getopt_long?
Date: Fri, 21 Nov 2014 19:49:55 +0100	[thread overview]
Message-ID: <20141121184955.GA2284@euler> (raw)
In-Reply-To: <20141119225044.GP22465@brightrain.aerifal.cx>

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 <stdio.h>
> > #include <getopt.h>
> > 
> > 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


      reply	other threads:[~2014-11-21 18:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-26  9:12 Felix Janda
2014-07-26  9:31 ` Rich Felker
2014-07-26 17:48   ` Felix Janda
2014-07-26 18:34     ` Rich Felker
2014-07-27 18:35     ` Rich Felker
2014-07-27 22:30       ` Felix Janda
2014-11-19 17:42         ` Rich Felker
2014-11-19 18:44           ` Felix Janda
2014-11-19 22:50             ` Rich Felker
2014-11-21 18:49               ` Felix Janda [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141121184955.GA2284@euler \
    --to=felix.janda@posteo.de \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).