Re: getopt reinvocation/reentrancy

[Gregory Pietsch <gpietsch at comcast dot net>]

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