| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
it's not ideal, but the function is essentially an extended stdio
function specialized to getopt's needs. the only reason it exists is
avoiding pulling printf code into every program using getopt.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for getopt_long, partial (prefix) matches of long options always begin
with "--" and thus can never be ambiguous with a short option. for
getopt_long_only, though, a single-character option can match both a
short option and as a prefix for a long option. in this case, we
wrongly interpreted it as a prefix for the long option.
introduce a new pass, only in long-only mode, to check the prefix
match against short options before accepting it. the only reason
there's a slightly nontrivial loop being introduced rather than strchr
is that our getopt already supports multibyte short options, and
getopt_long_long should handle them consistently. a temp buffer and
strstr could have been used, but the code to set it up would be just
as large as what's introduced here and it would unnecessarily pull in
relatively large code for strstr.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Consider the first equals sign found in the option to be the delimiter
between it and its argument, even if it matches an equals sign in the
option name. This avoids consuming the equals sign, which would prevent
finding the argument. Instead, it forces a partial match of the part of
the option name before the equals sign.
Maintainer's note: GNU getopt_long does not explicitly document this
behavior, but it can be seen as a consequence of how partial matches
are specified, and at least GNU (bfd) ld is known to make use of it.
|
| |
|
|
|
|
|
| |
If we find a partial option name match, we need to keep looking for
ambiguous/conflicting options. However, we need to remember the position
in the candidate argument to find its option-argument later, if there is
one. This fixes e.g. option "foobar" being given as "--fooba=baz".
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
getopt is only specified to modify optopt on error, and some software
apparently infers an error from optopt!=0.
getopt_long is changed analogously. the resulting behavior differs
slightly from the behavior of the GNU implementation of getopt_long,
which keeps an internal shadow copy of optopt and copies it to the
public one on return, but since the GNU implementation also exhibits
this shadow-copy behavior for plain getopt where is is non-conforming,
I think this can reasonably be considered a bug rather than an
intentional behavior that merits mimicing.
|
| | |
|
| |
|
|
|
|
|
| |
as a result of commit e8e4e56a8ce1f3d7e4a027ff5478f2f8ea70c46b,
the later code path for setting optarg to a null pointer is no longer
necessary, and removing it eliminates an indention level and arguably
makes the code more readable.
|
| |
|
|
|
|
|
|
|
|
|
| |
the standard getopt does not touch optarg unless processing an option
with an argument. however, programs using the GNU getopt API, which we
attempt to provide in getopt_long, expect optarg to be a null pointer
after processing an option without an argument.
before argument permutation support was added, such programs typically
detected its absence and used their own replacement getopt_long,
masking the discrepency in behavior.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit b72cd07f176b876aa51864d93aa8101477b1d732 added support for a
this feature in getopt, but it was later broken in the case where
getopt_long is used as a side effect of the changes made in commit
91184c4f16b143107fa9935edebe5d2b20bd70d8, which prevented the
underlying getopt call from seeing the leading '-' or '+' character in
optstring.
this commit changes the logic in the getopt_long core to check for a
leading colon, possibly after the leading '-' or '+', without
depending on the latter having been skipped by the caller. a minor
incorrectness in the return value for one error condition in
getopt_long is also fixed when opterr has been set to zero but
optstring has no leading ':'.
|
| |
|
|
|
|
| |
this is undocumented but possibly expected behavior of GNU
getopt_long, and useful when error message printing has been
suppressed.
|
| |
|
|
|
| |
some related changes are also made to getopt, and the return value of
getopt_long in the case of missing arguments is fixed.
|
| | |
|
| |
|
|
|
|
| |
if argv permutation is used, the option terminator "--" should be
moved before any skipped non-option arguments rather than being left
in the argv tail where the caller will see and interpret it.
|
| |
|
|
|
| |
this is an undocumented feature of GNU getopt_long that the BSD
version also mimics, and is reportedly needed by some programs.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
this is a GNU extension, activated by including '-' as the first
character of the options string, whereby non-option arguments are
processed as if they were arguments to an option character '\1' rather
than ending option processing.
|
| |
|
|
|
|
|
| |
based on proposed patches by Daniel Cegiełka, with minor changes:
- use a weak symbol for optreset so it doesn't clash with namespace
- also reset optpos (position in multi-option arg like -lR)
- also make getopt_long support reset
|
|
|
previously, it was pretty much random which one of these trees a given
function appeared in. they have now been organized into:
src/linux: non-POSIX linux syscalls (possibly shard with other nixen)
src/legacy: various obsolete/legacy functions, mostly wrappers
src/misc: still mostly uncategorized; some misc POSIX, some nonstd
src/crypt: crypt hash functions
further cleanup will be done later.
|
