This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: getopt reinvocation/reentrancy

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

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

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.


Probably, my changes broke your code, because it likely (bogusly) relies

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.

Temporarily I called memset to zero it out but that is also
making assumptions about the default values.


PS: Taking out Greg from the CC: because his rsp. his providers hostile
mailserver rejects mails from me.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]