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 are: -- 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
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"
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.