Thu Feb 28 23:22:00 GMT 2008
We have been working on the RTEMS Shell and
I noticed something that I don't know how to
properly deal with. I am sure it is beyond
the requirements of opengroup.
RTEMS applications are usually a single statically
linked executable so there can only be one main.
So we have main's for each command (e.g. main_cat(),
main_cp(), main_cpuuse(), etc.). Each main_XXX
is passed an argc, argv set and may use getopt()
to interpret it.
The problem is that newlib's getopt() uses global
variables to hold state as the arguments are parsed.
That is the crux of the reentrancy issue.
If you invoke getopt() to parse a second set of
options, the state information on the second set
is left over from the end of parsing the first set.
In the case I discovered this, I was doing this:
netstats -c -u -i
On the second netstats invocation, the state pointed
passed the end of the set of arguments so nothing
I am looking for suggestions on how to enhance
getopt to support this type of usage. I do not
see getopt_r in /usr/include on Fedora 8 but Google
shows that glibc had this type of functionality at
one point. I think the minimum requirement is a
parallel set of getoptXXX_r with a state variable that
can be initialized by the user.
I also noticed that stdlib/getopt.c has multiple
public API functions in it. Should these be broken
out? I know they are individually small but....
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
More information about the Newlib