This is the mail archive of the newlib@sourceware.org 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] |
Ralf Corsepius wrote:This doesn't make sense as those values should be in the interface (i.e. the header file).On Fri, 2008-03-07 at 12:52 -0600, Joel Sherrill wrote:
Jeff Johnston wrote:
Ralf Corsepius wrote:Google turned up an old patch. :)
On Mon, 2008-03-03 at 15:07 -0500, Gregory Pietsch wrote:
I got the definition of the GETOPT_DATA_INITIALIZER macro from that oldThen Joel might want to recheck his docs.
libc manual that Joel provided the link for:
http://sourceware.org/ml/libc-alpha/2004-03/msg00031/libc-manual.diff .
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.
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.
=> 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 beenI am ok with that. The GETOPT_DATA_INITIALIZER is the
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.
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.
--joelRalf
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] |