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