Bug 4116 - getopt_long does *not* return (or indicate in any way) error condition (if occurred) to programmer.
Summary: getopt_long does *not* return (or indicate in any way) error condition (if oc...
Alias: None
Product: glibc
Classification: Unclassified
Component: argparse (show other bugs)
Version: 2.4
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2007-03-01 11:58 UTC by Konstantin Andreev
Modified: 2018-04-20 21:01 UTC (History)
3 users (show)

See Also:
Last reconfirmed:
fweimer: security-


Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Andreev 2007-03-01 11:58:04 UTC
There are a lot of situations, where errors in options (and its arguments) can
not be reported to user by "getopt" internal routine:
  fprintf (stderr, _("%s: option `%s' ...

That's why variable "opterr" and optstring prefix ":" do exist: for disabling
"getopt" internal error reporting. The most apparent examples of such situations
-- we need to localize error messages for application which does not use
gettext, because it's mono-language (but not English).
-- in GUI application stderr is not visible to user (or even closed), and we
need to display errors in dialog window.

The plain short-option "getopt" provides programmer with sufficient information
to catch and handle errors: ":"/"?" as return code and "optopt" as subject of error.

But "getopt_long" provides NONE information to programmer. There are at least 4
(four) indistinguishable error conditions:

1) option is ambiguous
2) unrecognized/invalid option
3) option doesn't allow an argument
4) option requires an argument

In either of above "getopt_long" just return "?", leaving the programmer to
guess what's happened. Moreover, in cases (1) and (2) programmer doesn't even
know, which option has triggered the error.

So, "getopt_long" must be fixed to indicate 
A) different error conditions
B) the option (text) caused the error
Comment 1 Konstantin Andreev 2007-03-01 14:54:50 UTC
Though "getopt_long" points to an option in question in case of errors:

3) option doesn't allow an argument
4) option requires an argument

... by setting "optopt" variable, but leaves it's "longind" parameter untouched.
 This cause programmer either scan "longopts" array, or build one more
"switch(...)" to find the option in question.

So, "getopt_long" should be fixed to set "longind"
Comment 2 Florian Weimer 2018-04-20 13:58:06 UTC
The getopt_long interface is problematic in many ways, but it is unlikely that we'll ever add a different command line parsing facility to glibc, considering that there won't be any consensus what a replacement should look like or how it should behave.