[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