getopt reinvocation/reentrancy

[Joel Sherrill]

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 ) {

Doesn't work because getopt_reent isn't initialized.  And there is
no defined way in the getopt.h  in the latest RTEMS RPMs to address
that. 

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

--joel
> -- Jeff J.
>   


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