getopt reinvocation/reentrancy

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

Hi,

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
netstats -t

On the second netstats invocation, the state pointed
passed the end of the set of arguments so nothing
was parsed.

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

Any thoughts?

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