getopt reinvocation/reentrancy
Gregory Pietsch
gpietsch@comcast.net
Tue Mar 11 14:55:00 GMT 2008
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.
Gregory
>
>> Probably, my changes broke your code, because it likely (bogusly) relies
>> on presence of GETOPT_DATA_INITIALIZER.
>>
>>
> The getopt_reent structure is opaque to the caller and must
> be initialized somehow by the user or it is likely to contain
> random values from the stack. This has to be either
> some type of initializer constant or a call to an init function.
> I modeled my suggestion after what was proposed to be glibc
> at one point.
>
> http://sources.redhat.com/ml/libc-alpha/2004-03/msg00031.html
>
> Temporarily I called memset to zero it out but that is also
> making assumptions about the default values.
>
> --joel
>> Ralf
>>
>> PS: Taking out Greg from the CC: because his rsp. his providers hostile
>> mailserver rejects mails from me.
>>
More information about the Newlib
mailing list