diff options
author | Zack Weinberg <zackw@panix.com> | 2017-04-01 10:01:40 -0400 |
---|---|---|
committer | Zack Weinberg <zackw@panix.com> | 2017-04-07 07:47:58 -0400 |
commit | 7e161bef0bc9d5ea5e6f3dd490ecd5da6f642671 (patch) | |
tree | 36eed7d8575ac380c467429ef3bd76cf5e73fdae /posix/tst-getopt-cancel.c | |
parent | 7f71f9c1d6735e713de193faf03edb37c4bcb563 (diff) | |
download | glibc-7e161bef0bc9d5ea5e6f3dd490ecd5da6f642671.tar.gz glibc-7e161bef0bc9d5ea5e6f3dd490ecd5da6f642671.tar.xz glibc-7e161bef0bc9d5ea5e6f3dd490ecd5da6f642671.zip |
getopt: fix fencepost error in ambiguous-W-option handling
getopt_long contains an undocumented (AFAICT) feature in which, if you put "W;" in the short-options list, then '-W foo' and '-Wfoo' are treated as equivalent to '--foo'. This is implemented with a partial second copy of the code for handling long options, and that code increments optind one too many times when recovering from an ambiguous abbreviated option, which can cause the main loop to walk past the end of argv and crash. I discovered this while writing a test case that tries to exercise all of getopt's error reporting paths; I wouldn't be surprised to learn that this feature is never used by real applications. * posix/getopt.c (_getopt_internal_r): Don't increment d->optind a second time when reporting ambiguous -W options.
Diffstat (limited to 'posix/tst-getopt-cancel.c')
0 files changed, 0 insertions, 0 deletions