getopt reinvocation/reentrancy

[Joel Sherrill]

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.
>
> => 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.
> 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.
>
>
>
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985