#313175 argp option OPTION_ARG_OPTIONAL not documented correctly

Package:
libc6
Source:
glibc
Description:
GNU C Library: Shared libraries
Submitter:
Drew Parsons
Date:
2011-08-20 12:18:23 UTC
Severity:
normal
#313175#5
Date:
2005-06-12 10:31:42 UTC
From:
To:
libc provides argp, a helpful tool for managing command line arguments.

When a command line option is marked under argp as having an argument (a
value), as in "-r COUNT" rather than just "-r", then usually that argument is
demanded as mandatory.  The argument may be made option (so that -r uses a
default value) by marking the argument with the flag OPTION_ARG_OPTIONAL.

However, OPTION_ARG_OPTIONAL does not seem to be working as advertised.  If
"-r" is given on its own, then the program complains when executed,
providing the "usage" message as if the option were improperly used (that
is, as if the extra argument were mandatory).

Moreover, if the extra argument is provided, it does not seem to be read in
correctly.  That is, the argument is NULL when the option is handled in
parse_opt, the argp parser function, so the default value is always used,
never overridden.

The broken behaviour occurs for my own C++ program compiling with g++, and
also occurs with the sample code given in the libc docs at section 25.3.11.4
"A Program Using Multiple Combined Argp Parsers", compiled with gcc (the -r
or --repeat option).

Drew

#313175#10
Date:
2006-02-16 04:11:10 UTC
From:
To:
Attached is a minimal test case showing the problem.

Compile with "gcc -o minargp minargp.c",
run with somthing like "./minargp -r 15"
to get
	argument value for -r = (null)
	repeat count has been set to 10

Expected behaviour:
	argument value for -r = 15
	repeat count has been set to 15

Why is the argument value empty?

Drew

#313175#15
Date:
2006-02-16 10:42:47 UTC
From:
To:
Drew Parsons a écrit :

Using "./minargp -r15" is working, but the documentation explicitly
states that a space is allowed between the argument and the value. So it
looks like a bug in the glibc. I will try to have a look when I find time.

#313175#20
Date:
2006-02-16 13:22:19 UTC
From:
To:
Thanks for looking into it (and for pointing out that it works without
the space, I had missed that).

There's the two ways of supplying the short option, -r 15 and -r15.
Thinking about it, I guess it sort of makes sense that the version with
the space won't work when the value is optional.  Otherwise it can't
tell if you mean a command line value of "15" together with the default
value of -r (=10), or whether you wanted to set r to 15.  Perhaps the
documentation needs to be cleaned up rather than the code?

Drew

#313175#25
Date:
2011-08-20 12:13:46 UTC
From:
To:
found 313175 2.11.2-10
retitle 313175 argp option OPTION_ARG_OPTIONAL not documented correctly
quit
white-space; `argp_parse' already works as well as it can in this case
by accepting only `--NAME[=ARG]' and `-CHAR[ARG]' formats (no
white-space) and generating help and usage messages to this effect:

$ ARGP_HELP_FMT=dup-args ./minargp --help
Usage: minargp [OPTION...]
minimal argp test for OPTION_ARG_OPTIONAL.

  -r[COUNT], --repeat[=COUNT]   Repeat the output COUNT (default 10) times
  -?, --help                 Give this help list
      --usage                Give a short usage message
$ ARGP_HELP_FMT=dup-args ./minargp --usage
Usage: minargp [-?] [-r[COUNT]] [--repeat[=COUNT]] [--help] [--usage]


I can't think of any programs that actually permit a white-space
between an option and it's _optional_ argument, so I guess this is
perfectly fine behaviour, except that, as you say, the documentation does
not mention this:

`const char *arg'
      If non-zero, this is the name of an argument associated with
      this option, which must be provided (e.g., with the
      `--NAME=VALUE' or `-CHAR VALUE' syntaxes), unless the
      `OPTION_ARG_OPTIONAL' flag (*note Argp Option Flags::) is
      set, in which case it _may_ be provided.

Now this does not explicitly state that `-CHAR VALUE' is valid for
optional arguments, but to clear this up I think something like:

      ...
      set, in which case it _may_ be provided (however, only with
      the less ambiguous `--name[=VALUE]' or `-CHAR[VALUE]'
      syntaxes).

A better change would involve a longer note explaining why not
to accept white-space before optional arguments.