--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: libc6-dev: getopt_long error confusing on missing argument
- From: Michel Briand <michelbriand@free.fr>
- Date: Wed, 04 Feb 2009 18:27:19 +0100
- Message-id: <20090204172719.15984.46801.reportbug@eana.kheb.homelinux.org>
Package: libc6-dev
Version: 2.7-18
Severity: normal
As GNU documentation says, getopt_long would return '?'
when an option is missing from optstring and would return
':' when an option declared with ':' in optstring is parsed
but there is no argument.
info libc getopt (§25.2.1)
But calling getopt_long with an optstring that contains 'g:'
with arguments like this: app -g, lead to the '?' return code.
(Even if program is compiled with either __USE_GNU or __USE_XOPEN).
--
Test result:
$ ./test -g
Received options:
./test: option requires an argument -- g
error: option not understood: g
One could see that the '?' case is triggered, not the ':' case.
Cheers,
Michel
---
Test program:
#include <getopt.h>
#include <stdio.h>
int
main(int argc, char *argv[])
{
int c = 0;
struct option long_options[] = {
{"geometry", required_argument, NULL, 'g'},
{0, 0, 0, 0}
};
int option_index = 0;
printf("Received options:\n");
while ((c = getopt_long_only(argc, argv, "g:", long_options,
&option_index)) != -1) {
switch (c) {
case 0:
printf(" --%s\n", long_options[option_index].name);
break;
case '?':
printf("error: option not understood: %c\n", optopt);
goto getoutofhere;
break;
case ':':
printf("error: missing arguement for option: %c\n", optopt);
goto getoutofhere;
break;
default:
printf(" -%c\n", c);
}
}
getoutofhere:
if (optind < argc) {
printf("Non-option arguments:\n");
while (optind < argc)
printf(" %s\n", argv[optind++]);
}
return 0;
}
-- System Information:
Debian Release: 5.0
APT prefers testing
APT policy: (990, 'testing'), (888, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores)
Locale: LANG=fr_FR@euro, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6-dev depends on:
ii libc6 2.7-18 GNU C Library: Shared libraries
ii linux-libc-dev 2.6.26-13 Linux support headers for userspac
Versions of packages libc6-dev recommends:
ii gcc [c-compiler] 4:4.3.2-2 The GNU C compiler
ii gcc-3.4 [c-compiler] 3.4.6-9 The GNU C compiler
ii gcc-4.1 [c-compiler] 4.1.2-25 The GNU C compiler
ii gcc-4.2 [c-compiler] 4.2.4-6 The GNU C compiler
ii gcc-4.3 [c-compiler] 4.3.2-1.1 The GNU C compiler
Versions of packages libc6-dev suggests:
ii glibc-doc 2.7-18 GNU C Library: Documentation
ii manpages-dev 3.05-1 Manual pages about using GNU/Linux
-- no debconf information
--- End Message ---
--- Begin Message ---
On Wed, Jan 27, 2010 at 10:43:07PM +0100, Jano Kupec wrote:
> getopt/getopt_long is actually not supposed to return ':' if the
> optstring does not _begin_ with a colon (e.g. ":g:") or a +/- sign
> followed by a colon (e.g. "+:g" - this actually has another bug, but
> that's not what this report is about).
>
I agree, thanks for your analysis. JFTR, here is the corresponding part
of the manual (25.2.1):
| If getopt finds an option character in argv that was not included in
| options, or a missing option argument, it returns ‘?’ and sets the
| external variable optopt to the actual option character. If the first
| character of options is a colon (‘:’), then getopt returns ‘:’ instead
| of ‘?’ to indicate a missing option argument. In addition, if the
| external variable opterr is nonzero (which is the default), getopt
| prints an error message.
I am therefore closing the bug.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
--- End Message ---