[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gnulib] [PATCH] getopt, argp - reentrant getopt interface, argp fix

From: Marcus Brinkmann
Subject: [Bug-gnulib] [PATCH] getopt, argp - reentrant getopt interface, argp fixes
Date: Wed, 03 Mar 2004 23:41:02 +0100
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)


[Note: I am not subscribed to bug-gnulib]

the attached three patches make the following changes (this is only an
overview, a precise changelog comes with each patch):

1. Add new reentrant interfaces for getopt (getopt_r, getopt_long_r,
   getopt_long_only_r) and supporting data type (struct getopt_data)
2. Change argp to use the new reentrant getopt interfaces.
3. Document the new interfaces.

Currently, argp uses a recursive lock (if available) to protect its
getopt invocations, and uses a mutex on GNU/Hurd.  Either is not
ideal.  Changing getopt to be reentrant is quite straightforward, and
solves the issue.

As a consequence it is now completely safe to invoke argp within an
argp option handler, for example to parse some of the options in a
dynamically loaded plugin.  This is just one example for a useful
applications of this (and in fact my original motivation).

My changes are conservative.  What follows are potential issues with
regards to reentrancy and design alternatives.

* Instead of or in addition to providing getopt_r etc, one could
  provide a new interface that takes as an additional argument a flag
  that indicates which style of option parsing should be used.

  My reason for not doing this is that the _r extension is a
  no-brainer, design and implementation wise.

  If you want me to do this, please provide me with a prototype that
  reflects what you want to be done, and I can make appropriate

* getenv ("POSIXLY_CORRECT") is still called at initialization (for
  each "instance" of the parser).  What is needed is not the string
  content, but only the information "set" or "not set".  If this is
  not safe, one could add an argument to the prototype or a member to
  struct getopt_data that indicates if posix-correctness is desired.

  If you want me to do such a change, please indicate what's the
  prefered solution (a member in the struct or a function argument).
  This could be part of a more generic prototype (as indicated above).

* It is not safe to call getopt*_r on the same argument vector several
  times from different threads if reordering is enabled.  This is a
  documented limitation, and I don't think it can feasibly be avoided.

* If USE_NONOPTION_FLAGS is enabled (it is not, due to other problems
  with this concept), for each "instance" of the parser which is
  initialized it is checked if argc/argv is equal to
  __libc_argc/__libc_argv.  If yes, the nonoption flags as indicated
  by an environment variable that bash creates (created?)
  automatically are used to avoid interpreting wildcard expansions as

  This code is retained, and should still work as expected.  However,
  it emphasizes the limitation that no two instances of the parser
  must be created with the same argc/argv (which is
  __libc_argc/__libc_argv) concurrently.  The difference is that this
  limitation here even applies if you don't let getopt reorder the
  options (because otherwise there could be a race in the
  initialization when the nonoption flags are incorporated from global

  This code is defunct, and the situation where an actual race could
  occur is a bizarre corner case.  I am not really sure how to deal
  with this in the best way.  Maybe nonoption flags should be disabled
  for the reentrant interface, or be provided as function arguments.
  Maybe you want to remove this code alltogether.

Please let me know what you think about this.  The patch has received
some testing by me and Marco Gerards.  In particular, I audited the
code for reentrancy issues and run a modified glibc on my main system.
Thanks also to Roland for suggesting this approach.


Attachment: libc-getopt-r.diff
Description: Binary data

Attachment: libc-argp.diff
Description: Binary data

Attachment: libc-manual.diff
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]