This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: getopt reinvocation/reentrancy
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