[patch] Fix optional arguments in getopt.
Jeff Johnston
jjohnstn@redhat.com
Tue Feb 12 18:14:00 GMT 2008
Peter Rosin wrote:
> A while back Peter Rosin wrote:
>> I noticed that the getopt implementation does not handle optional
>> arguments very well. E.g. ./foo --listen, where listen is an optional
>> long argument, is interpreted to have an isten argument. Also, it is
>> broken if other short options precede an optional short option. I.e.
>> when -l is optional, ./foo -l works, but ./foo -il does not.
>>
>> Here is a small fix for that, please apply...
>>
>> I'm not on the list, please CC me. Thanks!
>>
>> Cheers,
>> Peter
>>
>>
>> * libc/stdlib/getopt.c (getopt_internal): Handle optional
>> arguments better for long options and short options not
>> appearing as the first option in a sequence.
>>
>> --- newlib/libc/stdlib/getopt.c 2008-02-04 11:21:50.242125000 +0100
>> +++ newlib/libc/stdlib/getopt.c 2008-02-04 11:25:11.867125000 +0100
>> @@ -308,13 +308,8 @@
>> case OPTIONAL_ARG:
>> if (*possible_arg == '=')
>> possible_arg++;
>> - if (*possible_arg != '\0')
>> - {
>> - optarg = possible_arg;
>> - optwhere = 1;
>> - }
>> - else
>> - optarg = NULL;
>> + optarg = (*possible_arg != '\0') ? possible_arg : NULL;
>> + optwhere = 1;
>> break;
>> case REQUIRED_ARG:
>> if (*possible_arg == '=')
>
> Ping? The patch is simple enough, always reset optwhere to 1 after handling
> an option with an optional argument.
>
Sorry, fell through the cracks. Patch applied.
-- Jeff J.
More information about the Newlib
mailing list