getopt reinvocation/reentrancy
Gregory Pietsch
gpietsch@comcast.net
Tue Mar 11 18:56:00 GMT 2008
Ralf Corsepius wrote:
> On Tue, 2008-03-11 at 10:39 -0400, Gregory Pietsch wrote:
>
>> Joel Sherrill wrote:
>>
>>> Ralf Corsepius wrote:
>>>
>>>> On Fri, 2008-03-07 at 12:52 -0600, Joel Sherrill wrote:
>>>>
>>>>
>>>>> Jeff Johnston wrote:
>>>>>
>>>>>
>>>>>> Ralf Corsepius wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Mon, 2008-03-03 at 15:07 -0500, Gregory Pietsch wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I got the definition of the GETOPT_DATA_INITIALIZER macro from
>>>>>>>> that old
>>>>>>>> libc manual that Joel provided the link for:
>>>>>>>> http://sourceware.org/ml/libc-alpha/2004-03/msg00031/libc-manual.diff
>>>>>>>> .
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Then Joel might want to recheck his docs.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> Google turned up an old patch. :)
>>>>>
>>>>>
>>>>>>> Current glibc doesn't have NO_ARG, REQUIRED_ARG, OPTIONAL_ARG nor
>>>>>>> GETOPT_DATA_INITIALIZER.
>>>>>>>
>>>>>>> FWIW: I removed these defines from the RTEMS newlib's sources.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> And fixed the RTEMS source that used them I see. :)
>>>>> Unfortunately that break the code.
>>>>>
>>>>> struct getopt_data getopt_reent;
>>>>>
>>>>> while ( (option = getopt_r( argc, argv, "Aimfpcutv", &getopt_reent))
>>>>> != -1 ) {
>>>>>
>>>>>
>>>> All I did was to move the *_ARG defines from newlib's getopt.h to
>>>> getopt.c, i.e. to make these defines private to getopt and to adopt
>>>> newlib-cvs's getopt.h+getopt.c to rtems's newlib.
>>>>
>> This doesn't make sense as those values should be in the interface (i.e.
>> the header file).
>>
>>>> => If these changes break your code, either this code is broken or
>>>> newlib's getopt_r is broken.
>>>>
>>>>
>>>>
>>>>>> Ok, here's what I did. The newlib extensions to getopt.h have been
>>>>>> placed under the flag __need_getopt_newlib. Applications ported from
>>>>>> glibc using getopt.h will be name-space equivalent (i.e. no NO_ARG or
>>>>>> GETOPT_DATA_INITIALIZER). Applications needing the reentrant
>>>>>> extensions
>>>>>> or preferring to use the old macros, may define __need_getopt_newlib
>>>>>> before including getopt.h. getopt.c defines this flag. I also
>>>>>> added a
>>>>>> flag around the whole getopt.c because x86-linux has its own
>>>>>> version of
>>>>>> getopt.h which obviously doesn't have the stuff needed to compile
>>>>>> getopt.c.
>>>>>>
>>>>>>
>>>>>>
>>>>> I am ok with that. The GETOPT_DATA_INITIALIZER is the
>>>>> only required one for the _r functions AFAIK though.
>>>>>
>>>>>
>>>> I don't see any relationship between GETOPT_DATA_INITIALIZER and your
>>>> problem, because GETOPT_DATA_INITIALIZER is not used inside of newlib.
>>>>
>>>>
>>>>
>>> Greg should comment on this based upon the implementation.
>>> I suspect it is just a reflection that getopt.c passes through
>>> the getopt_reent structure passed into it.
>>>
>> What the GETOPT_DATA_INITIALIZER macro contains are the initial values
>> for the reentrancy functions. The getopt() functions have to keep some
>> state between calls; they do so in optarg, opterr, optind, optopt, and
>> optwhere. The reentrant functions use values in the structure instead of
>> global variables. GETOPT_DATA_INITIALIZER is the initializer macro for
>> that structure. This should be in the interface as well.
>>
>
> I meanwhile think, these getopt* functions should be removed from
> newlib.
>
> They are non-standard, not even present in glibc, and they are a
> questionable design.
>
> Ralf
>
After I took the trouble to get them working? -- Gregory
More information about the Newlib
mailing list