This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
[PATCH 14/28] Thread safety documentation.
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: libc-alpha at sourceware dot org
- Date: Fri, 16 Aug 2013 05:34:17 -0300
- Subject: [PATCH 14/28] Thread safety documentation.
- References: <20130816081210 dot 22991 dot 30766 dot stgit at frit dot home>
for ChangeLog
* manual/getopt.texi: Document thread safety properties.
---
manual/getopt.texi | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/manual/getopt.texi b/manual/getopt.texi
index f0b7283..3c1f4de 100644
--- a/manual/getopt.texi
+++ b/manual/getopt.texi
@@ -60,6 +60,31 @@ option argument, for those options that accept arguments.
@comment unistd.h
@comment POSIX.2
@deftypefun int getopt (int @var{argc}, char *const *@var{argv}, const char *@var{options})
+@safety{@mtunsafe{xguargs, envromt, staticbuf}@asunsafe{asmalloc, asi18n, selfdeadlock, asynconsist}@acunsafe{memleak, lockleak, incansist}}
+@c It may swap argv elements but argv is not guarded, and the
+@c modifications may be partial in case of cancellation. Calling getenv
+@c also brings about thread-safety issues out of access and returning
+@c pointers into the globally shared environment array, just like
+@c calling gettext brings about a whole lot of AS and AC safety issues.
+@c The getopt API involves returning values in the non-thread-specific
+@c optarg variable, which adds another thread-safety issue. Given
+@c print_errors, it may output errors to stderr, which may
+@c self-deadlock, leak locks, or encounter (in a signal handler) or
+@c leave (in case of cancellation) stderr in an inconsistent state.
+@c Various implicit, indirect uses of malloc, in uses of memstream and
+@c asprintf for error-printing, bring about the usual malloc issues.
+@c (The explicit use of malloc in a conditional situation in
+@c _getopt_initialize is never exercised in glibc.)
+@c
+@c _getopt_internal
+@c _getopt_internal_r
+@c gettext
+@c _getopt_initialize
+@c getenv
+@c malloc if USE_NONOPTION_FLAGS, never defined in libc
+@c open_memstream
+@c lockfile, unlockfile, __fxprintf -> stderr
+@c asprintf
The @code{getopt} function gets the next option argument from the
argument list specified by the @var{argv} and @var{argc} arguments.
Normally these values come directly from the arguments received by
@@ -225,6 +250,8 @@ was seen.
@comment getopt.h
@comment GNU
@deftypefun int getopt_long (int @var{argc}, char *const *@var{argv}, const char *@var{shortopts}, const struct option *@var{longopts}, int *@var{indexptr})
+@safety{@mtunsafe{xguargs, envromt, staticbuf}@asunsafe{asmalloc, asi18n, selfdeadlock, asynconsist}@acunsafe{memleak, lockleak, incansist}}
+@c Same issues as getopt.
Decode options from the vector @var{argv} (whose length is @var{argc}).
The argument @var{shortopts} describes the short options to accept, just as
it does in @code{getopt}. The argument @var{longopts} describes the long
@@ -278,6 +305,8 @@ getopt functionality there is one more function available.
@comment getopt.h
@comment GNU
@deftypefun int getopt_long_only (int @var{argc}, char *const *@var{argv}, const char *@var{shortopts}, const struct option *@var{longopts}, int *@var{indexptr})
+@safety{@mtunsafe{xguargs, envromt, staticbuf}@asunsafe{asmalloc, asi18n, selfdeadlock, asynconsist}@acunsafe{memleak, lockleak, incansist}}
+@c Same issues as getopt.
The @code{getopt_long_only} function is equivalent to the
@code{getopt_long} function but it allows to specify the user of the