[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Commits] r25149 - in /fsf/trunk/libc: ./ manual/
- To: commits@xxxxxxxxxx
- Subject: [Commits] r25149 - in /fsf/trunk/libc: ./ manual/
- From: eglibc@xxxxxxxxxx
- Date: Wed, 29 Jan 2014 08:01:53 -0000
Author: eglibc
Date: Wed Jan 29 00:01:52 2014
New Revision: 25149
Log:
Import glibc-mainline for 2014-01-29
Modified:
fsf/trunk/libc/ChangeLog
fsf/trunk/libc/NEWS
fsf/trunk/libc/manual/argp.texi
fsf/trunk/libc/manual/arith.texi
fsf/trunk/libc/manual/conf.texi
fsf/trunk/libc/manual/crypt.texi
fsf/trunk/libc/manual/intro.texi
fsf/trunk/libc/manual/macros.texi
Modified: fsf/trunk/libc/ChangeLog
==============================================================================
--- fsf/trunk/libc/ChangeLog (original)
+++ fsf/trunk/libc/ChangeLog Wed Jan 29 00:01:52 2014
@@ -1,3 +1,26 @@
+2014-01-29 Alexandre Oliva <aoliva@xxxxxxxxxx>
+
+ * manual/crypt.texi: Document MTASC-safety properties.
+
+2014-01-29 Alexandre Oliva <aoliva@xxxxxxxxxx>
+
+ * manual/conf.texi: Document MTASC-safety properties.
+
+2014-01-29 Alexandre Oliva <aoliva@xxxxxxxxxx>
+
+ * manual/arith.texi: Document MTASC-safety properties.
+
+2014-01-29 Alexandre Oliva <aoliva@xxxxxxxxxx>
+
+ * manual/argp.texi: Document MTASC-safety properties.
+
+2014-01-29 Alexandre Oliva <aoliva@xxxxxxxxxx>
+
+ * manual/macros.texi: Introduce macros to document multi
+ thread, asynchronous signal and asynchronous cancellation
+ safety properties.
+ * manual/intro.texi: Introduce the properties themselves.
+
2014-01-27 Kaz Kojima <kkojima@xxxxxxxxxxxxxx>
* sysdeps/sh/sh4/Makefile: New file.
Modified: fsf/trunk/libc/NEWS
==============================================================================
--- fsf/trunk/libc/NEWS (original)
+++ fsf/trunk/libc/NEWS Wed Jan 29 00:01:52 2014
@@ -118,6 +118,9 @@
* The _BSD_SOURCE feature test macro no longer enables BSD interfaces that
conflict with POSIX. The libbsd-compat library (which was a dummy library
that did nothing) has also been removed.
+
+* Preliminary documentation about Multi-Thread, Async-Signal and
+ Async-Cancel Safety has been added.
Version 2.18
Modified: fsf/trunk/libc/manual/argp.texi
==============================================================================
--- fsf/trunk/libc/manual/argp.texi (original)
+++ fsf/trunk/libc/manual/argp.texi Wed Jan 29 00:01:52 2014
@@ -36,6 +36,35 @@
@comment argp.h
@comment GNU
@deftypefun {error_t} argp_parse (const struct argp *@var{argp}, int @var{argc}, char **@var{argv}, unsigned @var{flags}, int *@var{arg_index}, void *@var{input})
+@safety{@prelim{}@mtunsafe{@mtasurace{:argpbuf} @mtslocale{} @mtsenv{}}@asunsafe{@ascuheap{} @ascuintl{} @asulock{} @asucorrupt{}}@acunsafe{@acsmem{} @aculock{} @acucorrupt{}}}
+@c Optionally alloca()tes standard help options, initializes the parser,
+@c then parses individual args in a loop, and then finalizes.
+@c parser_init
+@c calc_sizes ok
+@c option_is_end ok
+@c malloc @ascuheap @acsmem
+@c parser_convert @mtslocale
+@c convert_options @mtslocale
+@c option_is_end ok
+@c option_is_short ok
+@c isprint, but locale may change within the loop
+@c find_long_option ok
+@c group_parse
+@c group->parser (from argp->parser)
+@c parser_parse_next
+@c getopt_long(_only)_r many issues, same as non_r minus @mtasurace
+@c parser_parse_arg
+@c group_parse dup
+@c parser_parse_opt
+@c group_parse dup
+@c argp_error dup @mtasurace:argpbuf @mtsenv @mtslocale @ascuheap @ascuintl @asucorrupt @acsmem @acucorrupt @aculock
+@c dgettext (bad key error) dup @mtsenv @asucorrupt @ascuheap @asulock @ascudlopen @acucorrupt @aculock @acsfd @acsmem
+@c parser_finalize
+@c group_parse
+@c fprintf dup @mtslocale @asucorrupt @aculock @acucorrupt [no @ascuheap @acsmem]
+@c dgettext dup @mtsenv @asucorrupt @ascuheap @asulock @ascudlopen @acucorrupt @aculock @acsfd @acsmem
+@c arg_state_help
+@c free dup @ascuhelp @acsmem
The @code{argp_parse} function parses the arguments in @var{argv}, of
length @var{argc}, using the argp parser @var{argp}. @xref{Argp
Parsers}. Passing a null pointer for @var{argp} is the same as using
@@ -660,6 +689,8 @@
@comment argp.h
@comment GNU
@deftypefun void argp_usage (const struct argp_state *@var{state})
+@safety{@prelim{}@mtunsafe{@mtasurace{:argpbuf} @mtsenv{} @mtslocale{}}@asunsafe{@ascuheap{} @ascuintl{} @asucorrupt{}}@acunsafe{@acsmem{} @acucorrupt{} @aculock{}}}
+@c Just calls argp_state_help with stderr and ARGP_HELP_STD_USAGE.
Outputs the standard usage message for the argp parser referred to by
@var{state} to @code{@var{state}->err_stream} and terminate the program
with @code{exit (argp_err_exit_status)}. @xref{Argp Global Variables}.
@@ -669,6 +700,13 @@
@comment argp.h
@comment GNU
@deftypefun void argp_error (const struct argp_state *@var{state}, const char *@var{fmt}, @dots{})
+@safety{@prelim{}@mtunsafe{@mtasurace{:argpbuf} @mtsenv{} @mtslocale{}}@asunsafe{@ascuheap{} @ascuintl{} @asucorrupt{}}@acunsafe{@acsmem{} @acucorrupt{} @aculock{}}}
+@c Lock stream, vasprintf the formatted message into a buffer, print the
+@c buffer prefixed by the short program name (in libc,
+@c argp_short_program_name is a macro that expands to
+@c program_invocation_short_name), releases the buffer, then call
+@c argp_state_help with stream and ARGP_HELP_STD_ERR, unlocking the
+@c stream at the end.
Prints the printf format string @var{fmt} and following args, preceded
by the program name and @samp{:}, and followed by a @w{@samp{Try @dots{}
--help}} message, and terminates the program with an exit status of
@@ -679,6 +717,12 @@
@comment argp.h
@comment GNU
@deftypefun void argp_failure (const struct argp_state *@var{state}, int @var{status}, int @var{errnum}, const char *@var{fmt}, @dots{})
+@safety{@prelim{}@mtsafe{}@asunsafe{@asucorrupt{} @ascuheap{}}@acunsafe{@aculock{} @acucorrupt{} @acsmem{}}}
+@c Lock stream, write out the short program name, vasprintf the optional
+@c formatted message to a buffer, print the buffer prefixed by colon and
+@c blank, release the buffer, call strerror_r with an automatic buffer,
+@c print it out after colon and blank, put[w]c a line break, unlock the
+@c stream, then exit unless ARGP_NO_EXIT.
Similar to the standard gnu error-reporting function @code{error}, this
prints the program name and @samp{:}, the printf format string
@var{fmt}, and the appropriate following args. If it is non-zero, the
@@ -695,6 +739,142 @@
@comment argp.h
@comment GNU
@deftypefun void argp_state_help (const struct argp_state *@var{state}, FILE *@var{stream}, unsigned @var{flags})
+@safety{@prelim{}@mtunsafe{@mtasurace{:argpbuf} @mtsenv{} @mtslocale{}}@asunsafe{@ascuheap{} @ascuintl{} @asucorrupt{}}@acunsafe{@acsmem{} @acucorrupt{} @aculock{}}}
+@c Just calls _help with the short program name and optionally exit.
+@c The main problems in _help, besides the usual issues with stream I/O
+@c and translation, are the use of a static buffer (uparams, thus
+@c @mtasurace:argpbuf) that makes the whole thing thread-unsafe, reading
+@c from the environment for ARGP_HELP_FMT, accessing the locale object
+@c multiple times.
+
+@c _help @mtsenv @mtasurace:argpbuf @mtslocale @ascuheap @ascuintl @asucorrupt @acsmem @acucorrupt @aculock
+@c dgettext @ascuintl
+@c flockfile @aculock
+@c funlockfile @aculock
+@c fill_in_uparams @mtsenv @mtasurace:argpbuf @mtslocale @asucorrupt @ascuheap @aculock @acucorrupt @acsmem
+@c argp_failure dup (status = errnum = 0)
+@c atoi dup @mtslocale
+@c argp_hol @ascuheap @acsmem
+@c make_hol @ascuheap @acsmem
+@c hol_add_cluster @ascuheap @acsmem
+@c hol_append @ascuheap @acsmem
+@c hol_set_group ok
+@c hol_find_entry ok
+@c hol_sort @mtslocale @acucorrupt
+@c qsort dup @acucorrupt
+@c hol_entry_qcmp @mtslocale
+@c hol_entry_cmp @mtslocale
+@c group_cmp ok
+@c hol_cluster_cmp ok
+@c group_cmp ok
+@c hol_entry_first_short @mtslocale
+@c hol_entry_short_iterate [@mtslocale]
+@c until_short ok
+@c oshort ok
+@c isprint ok
+@c odoc ok
+@c hol_entry_first_long ok
+@c canon_doc_option @mtslocale
+@c tolower dup
+@c hol_usage @mtslocale @ascuintl @ascuheap @acsmem
+@c hol_entry_short_iterate ok
+@c add_argless_short_opt ok
+@c argp_fmtstream_printf dup
+@c hol_entry_short_iterate @mtslocale @ascuintl @ascuheap @acsmem
+@c usage_argful_short_opt @mtslocale @ascuintl @ascuheap @acsmem
+@c dgettext dup
+@c argp_fmtstream_printf dup
+@c hol_entry_long_iterate @mtslocale @ascuintl @ascuheap @acsmem
+@c usage_long_opt @mtslocale @ascuintl @ascuheap @acsmem
+@c dgettext dup
+@c argp_fmtstream_printf dup
+@c hol_help @mtslocale @mtasurace:argpbuf @ascuheap @ascuintl @asucorrupt @acsmem @acucorrupt @aculock
+@c hol_entry_help @mtslocale @mtasurace:argpbuf @ascuheap @ascuintl @asucorrupt @acsmem @acucorrupt @aculock
+@c argp_fmtstream_set_lmargin dup
+@c argp_fmtstream_wmargin dup
+@c argp_fmtstream_set_wmargin dup
+@c comma @mtslocale @ascuheap @ascuintl @asucorrupt @acsmem @acucorrupt @aculock
+@c argp_fmtstream_putc dup
+@c hol_cluster_is_child ok
+@c argp_fmtstream_wmargin dup
+@c print_header dup
+@c argp_fmtstream_set_wmargin dup
+@c argp_fmtstream_puts dup
+@c indent_to dup
+@c argp_fmtstream_putc dup
+@c arg @mtslocale @ascuheap @acsmem
+@c argp_fmtstream_printf dup
+@c odoc dup
+@c argp_fmtstream_puts dup
+@c argp_fmtstream_printf dup
+@c print_header @mtslocale @mtasurace:argpbuf @ascuheap @ascuintl @asucorrupt @acsmem @acucorrupt @aculock
+@c dgettext dup
+@c filter_doc dup
+@c argp_fmtstream_putc dup
+@c indent_to dup
+@c argp_fmtstream_set_lmargin dup
+@c argp_fmtstream_set_wmargin dup
+@c argp_fmtstream_puts dup
+@c free dup
+@c filter_doc dup
+@c argp_fmtstream_point dup
+@c indent_to @mtslocale @ascuheap @asucorrupt @acsmem @acucorrupt @aculock
+@c argp_fmtstream_point dup
+@c argp_fmtstream_putc dup
+@c dgettext dup
+@c filter_doc dup
+@c argp_fmtstream_putc dup
+@c argp_fmtstream_puts dup
+@c free dup
+@c hol_free @ascuheap @acsmem
+@c free dup
+@c argp_args_levels ok
+@c argp_args_usage @mtslocale @ascuintl @ascuheap @asucorrupt @acsmem @acucorrupt @aculock
+@c dgettext dup
+@c filter_doc ok
+@c argp_input ok
+@c argp->help_filter
+@c space @mtslocale @ascuheap @asucorrupt @acsmem @acucorrupt @aculock
+@c argp_fmtstream_point dup
+@c argp_fmtstream_rmargin @mtslocale @asucorrupt @acucorrupt @aculock
+@c argp_fmtstream_update dup
+@c argp_fmtstream_putc dup
+@c argp_fmtstream_write dup
+@c free dup
+@c argp_doc @mtslocale @ascuheap @ascuintl @asucorrupt @acsmem @acucorrupt @aculock
+@c dgettext @ascuintl
+@c strndup @ascuheap @acsmem
+@c argp_input dup
+@c argp->help_filter
+@c argp_fmtstream_putc @mtslocale @ascuheap @asucorrupt @acsmem @acucorrupt @aculock
+@c argp_fmtstream_ensure dup
+@c argp_fmtstream_write dup
+@c argp_fmtstream_puts dup
+@c argp_fmtstream_point @mtslocale @asucorrupt @acucorrupt @aculock
+@c argp_fmtstream_update dup
+@c argp_fmtstream_lmargin dup
+@c free dup
+@c argp_make_fmtstream @ascuheap @acsmem
+@c argp_fmtstream_free @mtslocale @ascuheap @asucorrupt @acsmem @acucorrupt @aculock
+@c argp_fmtstream_update @mtslocale @asucorrupt @acucorrupt @aculock
+@c put[w]c_unlocked dup
+@c isblank in loop @mtslocale
+@c fxprintf @aculock
+@c fxprintf @aculock
+@c free dup
+@c argp_fmtstream_set_wmargin @mtslocale @asucorrupt @acucorrupt @aculock
+@c argp_fmtstream_update dup
+@c argp_fmtstream_printf @mtslocale @ascuheap @acsmem
+@c argp_fmtstream_ensure dup
+@c vsnprintf dup
+@c argp_fmtstream_set_lmargin @mtslocale @asucorrupt @acucorrupt @aculock
+@c argp_fmtstream_update dup
+@c argp_fmtstream_puts @mtslocale @ascuheap @asucorrupt @acsmem @acucorrupt @aculock
+@c argp_fmtstream_write @mtslocale @ascuheap @asucorrupt @acsmem @acucorrupt @aculock
+@c argp_fmtstream_ensure @mtslocale @ascuheap @asucorrupt @acsmem @acucorrupt @aculock
+@c argp_fmtstream_update dup
+@c fxprintf @aculock
+@c realloc @ascuheap @acsmem
Outputs a help message for the argp parser referred to by @var{state},
to @var{stream}. The @var{flags} argument determines what sort of help
message is produced. @xref{Argp Help Flags}.
@@ -928,6 +1108,8 @@
@comment argp.h
@comment GNU
@deftypefun void argp_help (const struct argp *@var{argp}, FILE *@var{stream}, unsigned @var{flags}, char *@var{name})
+@safety{@prelim{}@mtunsafe{@mtasurace{:argpbuf} @mtsenv{} @mtslocale{}}@asunsafe{@ascuheap{} @ascuintl{} @asucorrupt{}}@acunsafe{@acsmem{} @acucorrupt{} @aculock{}}}
+@c Just calls _help.
This outputs a help message for the argp parser @var{argp} to
@var{stream}. The type of messages printed will be determined by
@var{flags}.
Modified: fsf/trunk/libc/manual/arith.texi
==============================================================================
--- fsf/trunk/libc/manual/arith.texi (original)
+++ fsf/trunk/libc/manual/arith.texi Wed Jan 29 00:01:52 2014
@@ -160,6 +160,8 @@
@comment stdlib.h
@comment ISO
@deftypefun div_t div (int @var{numerator}, int @var{denominator})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
+@c Functions in this section are pure, and thus safe.
This function @code{div} computes the quotient and remainder from
the division of @var{numerator} by @var{denominator}, returning the
result in a structure of type @code{div_t}.
@@ -199,6 +201,7 @@
@comment stdlib.h
@comment ISO
@deftypefun ldiv_t ldiv (long int @var{numerator}, long int @var{denominator})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The @code{ldiv} function is similar to @code{div}, except that the
arguments are of type @code{long int} and the result is returned as a
structure of type @code{ldiv_t}.
@@ -225,6 +228,7 @@
@comment stdlib.h
@comment ISO
@deftypefun lldiv_t lldiv (long long int @var{numerator}, long long int @var{denominator})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The @code{lldiv} function is like the @code{div} function, but the
arguments are of type @code{long long int} and the result is returned as
a structure of type @code{lldiv_t}.
@@ -256,6 +260,7 @@
@comment inttypes.h
@comment ISO
@deftypefun imaxdiv_t imaxdiv (intmax_t @var{numerator}, intmax_t @var{denominator})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The @code{imaxdiv} function is like the @code{div} function, but the
arguments are of type @code{intmax_t} and the result is returned as
a structure of type @code{imaxdiv_t}.
@@ -318,6 +323,7 @@
@comment math.h
@comment ISO
@deftypefn {Macro} int fpclassify (@emph{float-type} @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This is a generic macro which works on all floating-point types and
which returns a value of type @code{int}. The possible values are:
@@ -354,6 +360,7 @@
@comment math.h
@comment ISO
@deftypefn {Macro} int isfinite (@emph{float-type} @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This macro returns a nonzero value if @var{x} is finite: not plus or
minus infinity, and not NaN. It is equivalent to
@@ -368,6 +375,7 @@
@comment math.h
@comment ISO
@deftypefn {Macro} int isnormal (@emph{float-type} @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This macro returns a nonzero value if @var{x} is finite and normalized.
It is equivalent to
@@ -379,6 +387,7 @@
@comment math.h
@comment ISO
@deftypefn {Macro} int isnan (@emph{float-type} @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This macro returns a nonzero value if @var{x} is NaN. It is equivalent
to
@@ -390,6 +399,7 @@
@comment math.h
@comment GNU
@deftypefn {Macro} int issignaling (@emph{float-type} @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This macro returns a nonzero value if @var{x} is a signaling NaN
(sNaN). It is based on draft TS 18661 and currently enabled as a GNU
extension.
@@ -410,6 +420,7 @@
@comment math.h
@comment BSD
@deftypefunx int isinfl (long double @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This function returns @code{-1} if @var{x} represents negative infinity,
@code{1} if @var{x} represents positive infinity, and @code{0} otherwise.
@end deftypefun
@@ -423,6 +434,7 @@
@comment math.h
@comment BSD
@deftypefunx int isnanl (long double @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This function returns a nonzero value if @var{x} is a ``not a number''
value, and zero otherwise.
@@ -445,6 +457,7 @@
@comment math.h
@comment BSD
@deftypefunx int finitel (long double @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This function returns a nonzero value if @var{x} is finite or a ``not a
number'' value, and zero otherwise.
@end deftypefun
@@ -714,6 +727,14 @@
@comment fenv.h
@comment ISO
@deftypefun int feclearexcept (int @var{excepts})
+@safety{@prelim{}@mtsafe{}@assafe{@assposix{}}@acsafe{@acsposix{}}}
+@c The other functions in this section that modify FP status register
+@c mostly do so with non-atomic load-modify-store sequences, but since
+@c the register is thread-specific, this should be fine, and safe for
+@c cancellation. As long as the FP environment is restored before the
+@c signal handler returns control to the interrupted thread (like any
+@c kernel should do), the functions are also safe for use in signal
+@c handlers.
This function clears all of the supported exception flags indicated by
@var{excepts}.
@@ -724,6 +745,7 @@
@comment fenv.h
@comment ISO
@deftypefun int feraiseexcept (int @var{excepts})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This function raises the supported exceptions indicated by
@var{excepts}. If more than one exception bit in @var{excepts} is set
the order in which the exceptions are raised is undefined except that
@@ -739,6 +761,7 @@
@comment fenv.h
@comment ISO
@deftypefun int fetestexcept (int @var{excepts})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
Test whether the exception flags indicated by the parameter @var{except}
are currently set. If any of them are, a nonzero value is returned
which specifies which exceptions are set. Otherwise the result is zero.
@@ -775,6 +798,7 @@
@comment fenv.h
@comment ISO
@deftypefun int fegetexceptflag (fexcept_t *@var{flagp}, int @var{excepts})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This function stores in the variable pointed to by @var{flagp} an
implementation-defined value representing the current setting of the
exception flags indicated by @var{excepts}.
@@ -786,6 +810,7 @@
@comment fenv.h
@comment ISO
@deftypefun int fesetexceptflag (const fexcept_t *@var{flagp}, int @var{excepts})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This function restores the flags for the exceptions indicated by
@var{excepts} to the values stored in the variable pointed to by
@var{flagp}.
@@ -951,6 +976,7 @@
@comment fenv.h
@comment ISO
@deftypefun int fegetround (void)
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
Returns the currently selected rounding mode, represented by one of the
values of the defined rounding mode macros.
@end deftypefun
@@ -961,6 +987,7 @@
@comment fenv.h
@comment ISO
@deftypefun int fesetround (int @var{round})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
Changes the currently selected rounding mode to @var{round}. If
@var{round} does not correspond to one of the supported rounding modes
nothing is changed. @code{fesetround} returns zero if it changed the
@@ -1005,6 +1032,7 @@
@comment fenv.h
@comment ISO
@deftypefun int fegetenv (fenv_t *@var{envp})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
Store the floating-point environment in the variable pointed to by
@var{envp}.
@@ -1015,6 +1043,7 @@
@comment fenv.h
@comment ISO
@deftypefun int feholdexcept (fenv_t *@var{envp})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
Store the current floating-point environment in the object pointed to by
@var{envp}. Then clear all exception flags, and set the FPU to trap no
exceptions. Not all FPUs support trapping no exceptions; if
@@ -1053,6 +1082,7 @@
@comment fenv.h
@comment ISO
@deftypefun int fesetenv (const fenv_t *@var{envp})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
Set the floating-point environment to that described by @var{envp}.
The function returns zero in case the operation was successful, a
@@ -1062,6 +1092,7 @@
@comment fenv.h
@comment ISO
@deftypefun int feupdateenv (const fenv_t *@var{envp})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
Like @code{fesetenv}, this function sets the floating-point environment
to that described by @var{envp}. However, if any exceptions were
flagged in the status word before @code{feupdateenv} was called, they
@@ -1082,6 +1113,7 @@
@comment fenv.h
@comment GNU
@deftypefun int feenableexcept (int @var{excepts})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This functions enables traps for each of the exceptions as indicated by
the parameter @var{except}. The individual exceptions are described in
@ref{Status bit operations}. Only the specified exceptions are
@@ -1094,6 +1126,7 @@
@comment fenv.h
@comment GNU
@deftypefun int fedisableexcept (int @var{excepts})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This functions disables traps for each of the exceptions as indicated by
the parameter @var{except}. The individual exceptions are described in
@ref{Status bit operations}. Only the specified exceptions are
@@ -1106,6 +1139,7 @@
@comment fenv.h
@comment GNU
@deftypefun int fegetexcept (void)
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The function returns a bitmask of all currently enabled exceptions. It
returns @code{-1} in case of failure.
@end deftypefun
@@ -1157,6 +1191,7 @@
@comment inttypes.h
@comment ISO
@deftypefunx intmax_t imaxabs (intmax_t @var{number})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions return the absolute value of @var{number}.
Most computers use a two's complement integer representation, in which
@@ -1178,6 +1213,7 @@
@comment math.h
@comment ISO
@deftypefunx {long double} fabsl (long double @var{number})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This function returns the absolute value of the floating-point number
@var{number}.
@end deftypefun
@@ -1191,6 +1227,7 @@
@comment complex.h
@comment ISO
@deftypefunx {long double} cabsl (complex long double @var{z})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions return the absolute value of the complex number @var{z}
(@pxref{Complex Numbers}). The absolute value of a complex number is:
@@ -1228,6 +1265,7 @@
@comment math.h
@comment ISO
@deftypefunx {long double} frexpl (long double @var{value}, int *@var{exponent})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions are used to split the number @var{value}
into a normalized fraction and an exponent.
@@ -1253,6 +1291,7 @@
@comment math.h
@comment ISO
@deftypefunx {long double} ldexpl (long double @var{value}, int @var{exponent})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions return the result of multiplying the floating-point
number @var{value} by 2 raised to the power @var{exponent}. (It can
be used to reassemble floating-point numbers that were taken apart
@@ -1274,6 +1313,7 @@
@comment math.h
@comment BSD
@deftypefunx {long double} scalbl (long double @var{value}, long double @var{exponent})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The @code{scalb} function is the BSD name for @code{ldexp}.
@end deftypefun
@@ -1286,6 +1326,7 @@
@comment math.h
@comment BSD
@deftypefunx {long double} scalbnl (long double @var{x}, int @var{n})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
@code{scalbn} is identical to @code{scalb}, except that the exponent
@var{n} is an @code{int} instead of a floating-point number.
@end deftypefun
@@ -1299,6 +1340,7 @@
@comment math.h
@comment BSD
@deftypefunx {long double} scalblnl (long double @var{x}, long int @var{n})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
@code{scalbln} is identical to @code{scalb}, except that the exponent
@var{n} is a @code{long int} instead of a floating-point number.
@end deftypefun
@@ -1312,6 +1354,7 @@
@comment math.h
@comment BSD
@deftypefunx {long double} significandl (long double @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
@code{significand} returns the mantissa of @var{x} scaled to the range
@math{[1, 2)}.
It is equivalent to @w{@code{scalb (@var{x}, (double) -ilogb (@var{x}))}}.
@@ -1346,6 +1389,7 @@
@comment math.h
@comment ISO
@deftypefunx {long double} ceill (long double @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions round @var{x} upwards to the nearest integer,
returning that value as a @code{double}. Thus, @code{ceil (1.5)}
is @code{2.0}.
@@ -1360,6 +1404,7 @@
@comment math.h
@comment ISO
@deftypefunx {long double} floorl (long double @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions round @var{x} downwards to the nearest
integer, returning that value as a @code{double}. Thus, @code{floor
(1.5)} is @code{1.0} and @code{floor (-1.5)} is @code{-2.0}.
@@ -1374,6 +1419,7 @@
@comment math.h
@comment ISO
@deftypefunx {long double} truncl (long double @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The @code{trunc} functions round @var{x} towards zero to the nearest
integer (returned in floating-point format). Thus, @code{trunc (1.5)}
is @code{1.0} and @code{trunc (-1.5)} is @code{-1.0}.
@@ -1388,6 +1434,7 @@
@comment math.h
@comment ISO
@deftypefunx {long double} rintl (long double @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions round @var{x} to an integer value according to the
current rounding mode. @xref{Floating Point Parameters}, for
information about the various rounding modes. The default
@@ -1408,6 +1455,7 @@
@comment math.h
@comment ISO
@deftypefunx {long double} nearbyintl (long double @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions return the same value as the @code{rint} functions, but
do not raise the inexact exception if @var{x} is not an integer.
@end deftypefun
@@ -1421,6 +1469,7 @@
@comment math.h
@comment ISO
@deftypefunx {long double} roundl (long double @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions are similar to @code{rint}, but they round halfway
cases away from zero instead of to the nearest integer (or other
current rounding mode).
@@ -1435,6 +1484,7 @@
@comment math.h
@comment ISO
@deftypefunx {long int} lrintl (long double @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions are just like @code{rint}, but they return a
@code{long int} instead of a floating-point number.
@end deftypefun
@@ -1448,6 +1498,7 @@
@comment math.h
@comment ISO
@deftypefunx {long long int} llrintl (long double @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions are just like @code{rint}, but they return a
@code{long long int} instead of a floating-point number.
@end deftypefun
@@ -1461,6 +1512,7 @@
@comment math.h
@comment ISO
@deftypefunx {long int} lroundl (long double @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions are just like @code{round}, but they return a
@code{long int} instead of a floating-point number.
@end deftypefun
@@ -1474,6 +1526,7 @@
@comment math.h
@comment ISO
@deftypefunx {long long int} llroundl (long double @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions are just like @code{round}, but they return a
@code{long long int} instead of a floating-point number.
@end deftypefun
@@ -1488,6 +1541,7 @@
@comment math.h
@comment ISO
@deftypefunx {long double} modfl (long double @var{value}, long double *@var{integer-part})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions break the argument @var{value} into an integer part and a
fractional part (between @code{-1} and @code{1}, exclusive). Their sum
equals @var{value}. Each of the parts has the same sign as @var{value},
@@ -1514,6 +1568,7 @@
@comment math.h
@comment ISO
@deftypefunx {long double} fmodl (long double @var{numerator}, long double @var{denominator})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions compute the remainder from the division of
@var{numerator} by @var{denominator}. Specifically, the return value is
@code{@var{numerator} - @w{@var{n} * @var{denominator}}}, where @var{n}
@@ -1536,6 +1591,7 @@
@comment math.h
@comment BSD
@deftypefunx {long double} dreml (long double @var{numerator}, long double @var{denominator})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions are like @code{fmod} except that they round the
internal quotient @var{n} to the nearest integer instead of towards zero
to an integer. For example, @code{drem (6.5, 2.3)} returns @code{-0.4},
@@ -1559,6 +1615,7 @@
@comment math.h
@comment BSD
@deftypefunx {long double} remainderl (long double @var{numerator}, long double @var{denominator})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This function is another name for @code{drem}.
@end deftypefun
@@ -1580,6 +1637,7 @@
@comment math.h
@comment ISO
@deftypefunx {long double} copysignl (long double @var{x}, long double @var{y})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions return @var{x} but with the sign of @var{y}. They work
even if @var{x} or @var{y} are NaN or zero. Both of these can carry a
sign (although not all implementations support it) and this is one of
@@ -1595,6 +1653,7 @@
@comment math.h
@comment ISO
@deftypefun int signbit (@emph{float-type} @var{x})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
@code{signbit} is a generic macro which can work on all floating-point
types. It returns a nonzero value if the value of @var{x} has its sign
bit set.
@@ -1613,6 +1672,7 @@
@comment math.h
@comment ISO
@deftypefunx {long double} nextafterl (long double @var{x}, long double @var{y})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The @code{nextafter} function returns the next representable neighbor of
@var{x} in the direction towards @var{y}. The size of the step between
@var{x} and the result depends on the type of the result. If
@@ -1636,6 +1696,7 @@
@comment math.h
@comment ISO
@deftypefunx {long double} nexttowardl (long double @var{x}, long double @var{y})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions are identical to the corresponding versions of
@code{nextafter} except that their second argument is a @code{long
double}.
@@ -1651,6 +1712,8 @@
@comment math.h
@comment ISO
@deftypefunx {long double} nanl (const char *@var{tagp})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
+@c The unsafe-but-ruled-safe locale use comes from strtod.
The @code{nan} function returns a representation of NaN, provided that
NaN is supported by the target platform.
@code{nan ("@var{n-char-sequence}")} is equivalent to
@@ -1685,6 +1748,7 @@
@comment math.h
@comment ISO
@deftypefn Macro int isgreater (@emph{real-floating} @var{x}, @emph{real-floating} @var{y})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This macro determines whether the argument @var{x} is greater than
@var{y}. It is equivalent to @code{(@var{x}) > (@var{y})}, but no
exception is raised if @var{x} or @var{y} are NaN.
@@ -1693,6 +1757,7 @@
@comment math.h
@comment ISO
@deftypefn Macro int isgreaterequal (@emph{real-floating} @var{x}, @emph{real-floating} @var{y})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This macro determines whether the argument @var{x} is greater than or
equal to @var{y}. It is equivalent to @code{(@var{x}) >= (@var{y})}, but no
exception is raised if @var{x} or @var{y} are NaN.
@@ -1701,6 +1766,7 @@
@comment math.h
@comment ISO
@deftypefn Macro int isless (@emph{real-floating} @var{x}, @emph{real-floating} @var{y})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This macro determines whether the argument @var{x} is less than @var{y}.
It is equivalent to @code{(@var{x}) < (@var{y})}, but no exception is
raised if @var{x} or @var{y} are NaN.
@@ -1709,6 +1775,7 @@
@comment math.h
@comment ISO
@deftypefn Macro int islessequal (@emph{real-floating} @var{x}, @emph{real-floating} @var{y})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This macro determines whether the argument @var{x} is less than or equal
to @var{y}. It is equivalent to @code{(@var{x}) <= (@var{y})}, but no
exception is raised if @var{x} or @var{y} are NaN.
@@ -1717,6 +1784,7 @@
@comment math.h
@comment ISO
@deftypefn Macro int islessgreater (@emph{real-floating} @var{x}, @emph{real-floating} @var{y})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This macro determines whether the argument @var{x} is less or greater
than @var{y}. It is equivalent to @code{(@var{x}) < (@var{y}) ||
(@var{x}) > (@var{y})} (although it only evaluates @var{x} and @var{y}
@@ -1729,6 +1797,7 @@
@comment math.h
@comment ISO
@deftypefn Macro int isunordered (@emph{real-floating} @var{x}, @emph{real-floating} @var{y})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This macro determines whether its arguments are unordered. In other
words, it is true if @var{x} or @var{y} are NaN, and false otherwise.
@end deftypefn
@@ -1762,6 +1831,7 @@
@comment math.h
@comment ISO
@deftypefunx {long double} fminl (long double @var{x}, long double @var{y})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The @code{fmin} function returns the lesser of the two values @var{x}
and @var{y}. It is similar to the expression
@smallexample
@@ -1782,6 +1852,7 @@
@comment math.h
@comment ISO
@deftypefunx {long double} fmaxl (long double @var{x}, long double @var{y})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The @code{fmax} function returns the greater of the two values @var{x}
and @var{y}.
@@ -1798,6 +1869,7 @@
@comment math.h
@comment ISO
@deftypefunx {long double} fdiml (long double @var{x}, long double @var{y})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The @code{fdim} function returns the positive difference between
@var{x} and @var{y}. The positive difference is @math{@var{x} -
@var{y}} if @var{x} is greater than @var{y}, and @math{0} otherwise.
@@ -1815,6 +1887,7 @@
@comment ISO
@deftypefunx {long double} fmal (long double @var{x}, long double @var{y}, long double @var{z})
@cindex butterfly
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The @code{fma} function performs floating-point multiply-add. This is
the operation @math{(@var{x} @mul{} @var{y}) + @var{z}}, but the
intermediate result is not rounded to the destination type. This can
@@ -1944,6 +2017,7 @@
@comment complex.h
@comment ISO
@deftypefunx {long double} creall (complex long double @var{z})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions return the real part of the complex number @var{z}.
@end deftypefun
@@ -1956,6 +2030,7 @@
@comment complex.h
@comment ISO
@deftypefunx {long double} cimagl (complex long double @var{z})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions return the imaginary part of the complex number @var{z}.
@end deftypefun
@@ -1968,6 +2043,7 @@
@comment complex.h
@comment ISO
@deftypefunx {complex long double} conjl (complex long double @var{z})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions return the conjugate value of the complex number
@var{z}. The conjugate of a complex number has the same real part and a
negated imaginary part. In other words, @samp{conj(a + bi) = a + -bi}.
@@ -1982,6 +2058,7 @@
@comment complex.h
@comment ISO
@deftypefunx {long double} cargl (complex long double @var{z})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions return the argument of the complex number @var{z}.
The argument of a complex number is the angle in the complex plane
between the positive real axis and a line passing through zero and the
@@ -2000,6 +2077,7 @@
@comment complex.h
@comment ISO
@deftypefunx {complex long double} cprojl (complex long double @var{z})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
These functions return the projection of the complex value @var{z} onto
the Riemann sphere. Values with an infinite imaginary part are projected
to positive infinity on the real axis, even if the real part is NaN. If
@@ -2045,6 +2123,15 @@
@comment stdlib.h
@comment ISO
@deftypefun {long int} strtol (const char *restrict @var{string}, char **restrict @var{tailptr}, int @var{base})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
+@c strtol uses the thread-local pointer to the locale in effect, and
+@c strtol_l loads the LC_NUMERIC locale data from it early on and once,
+@c but if the locale is the global locale, and another thread calls
+@c setlocale in a way that modifies the pointer to the LC_CTYPE locale
+@c category, the behavior of e.g. IS*, TOUPPER will vary throughout the
+@c execution of the function, because they re-read the locale data from
+@c the given locale pointer. We solved this by documenting setlocale as
+@c MT-Unsafe.
The @code{strtol} (``string-to-long'') function converts the initial
part of @var{string} to a signed integer, which is returned as a value
of type @code{long int}.
@@ -2108,6 +2195,7 @@
@comment wchar.h
@comment ISO
@deftypefun {long int} wcstol (const wchar_t *restrict @var{string}, wchar_t **restrict @var{tailptr}, int @var{base})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
The @code{wcstol} function is equivalent to the @code{strtol} function
in nearly all aspects but handles wide character strings.
@@ -2117,6 +2205,7 @@
@comment stdlib.h
@comment ISO
@deftypefun {unsigned long int} strtoul (const char *retrict @var{string}, char **restrict @var{tailptr}, int @var{base})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
The @code{strtoul} (``string-to-unsigned-long'') function is like
@code{strtol} except it converts to an @code{unsigned long int} value.
The syntax is the same as described above for @code{strtol}. The value
@@ -2135,6 +2224,7 @@
@comment wchar.h
@comment ISO
@deftypefun {unsigned long int} wcstoul (const wchar_t *restrict @var{string}, wchar_t **restrict @var{tailptr}, int @var{base})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
The @code{wcstoul} function is equivalent to the @code{strtoul} function
in nearly all aspects but handles wide character strings.
@@ -2144,6 +2234,7 @@
@comment stdlib.h
@comment ISO
@deftypefun {long long int} strtoll (const char *restrict @var{string}, char **restrict @var{tailptr}, int @var{base})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
The @code{strtoll} function is like @code{strtol} except that it returns
a @code{long long int} value, and accepts numbers with a correspondingly
larger range.
@@ -2160,6 +2251,7 @@
@comment wchar.h
@comment ISO
@deftypefun {long long int} wcstoll (const wchar_t *restrict @var{string}, wchar_t **restrict @var{tailptr}, int @var{base})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
The @code{wcstoll} function is equivalent to the @code{strtoll} function
in nearly all aspects but handles wide character strings.
@@ -2169,12 +2261,14 @@
@comment stdlib.h
@comment BSD
@deftypefun {long long int} strtoq (const char *restrict @var{string}, char **restrict @var{tailptr}, int @var{base})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
@code{strtoq} (``string-to-quad-word'') is the BSD name for @code{strtoll}.
@end deftypefun
@comment wchar.h
@comment GNU
@deftypefun {long long int} wcstoq (const wchar_t *restrict @var{string}, wchar_t **restrict @var{tailptr}, int @var{base})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
The @code{wcstoq} function is equivalent to the @code{strtoq} function
in nearly all aspects but handles wide character strings.
@@ -2184,6 +2278,7 @@
@comment stdlib.h
@comment ISO
@deftypefun {unsigned long long int} strtoull (const char *restrict @var{string}, char **restrict @var{tailptr}, int @var{base})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
The @code{strtoull} function is related to @code{strtoll} the same way
@code{strtoul} is related to @code{strtol}.
@@ -2193,6 +2288,7 @@
@comment wchar.h
@comment ISO
@deftypefun {unsigned long long int} wcstoull (const wchar_t *restrict @var{string}, wchar_t **restrict @var{tailptr}, int @var{base})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
The @code{wcstoull} function is equivalent to the @code{strtoull} function
in nearly all aspects but handles wide character strings.
@@ -2202,12 +2298,14 @@
@comment stdlib.h
@comment BSD
@deftypefun {unsigned long long int} strtouq (const char *restrict @var{string}, char **restrict @var{tailptr}, int @var{base})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
@code{strtouq} is the BSD name for @code{strtoull}.
@end deftypefun
@comment wchar.h
@comment GNU
@deftypefun {unsigned long long int} wcstouq (const wchar_t *restrict @var{string}, wchar_t **restrict @var{tailptr}, int @var{base})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
The @code{wcstouq} function is equivalent to the @code{strtouq} function
in nearly all aspects but handles wide character strings.
@@ -2217,6 +2315,7 @@
@comment inttypes.h
@comment ISO
@deftypefun intmax_t strtoimax (const char *restrict @var{string}, char **restrict @var{tailptr}, int @var{base})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
The @code{strtoimax} function is like @code{strtol} except that it returns
a @code{intmax_t} value, and accepts numbers of a corresponding range.
@@ -2233,6 +2332,7 @@
@comment wchar.h
@comment ISO
@deftypefun intmax_t wcstoimax (const wchar_t *restrict @var{string}, wchar_t **restrict @var{tailptr}, int @var{base})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
The @code{wcstoimax} function is equivalent to the @code{strtoimax} function
in nearly all aspects but handles wide character strings.
@@ -2242,6 +2342,7 @@
@comment inttypes.h
@comment ISO
@deftypefun uintmax_t strtoumax (const char *restrict @var{string}, char **restrict @var{tailptr}, int @var{base})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
The @code{strtoumax} function is related to @code{strtoimax}
the same way that @code{strtoul} is related to @code{strtol}.
@@ -2252,6 +2353,7 @@
@comment wchar.h
@comment ISO
@deftypefun uintmax_t wcstoumax (const wchar_t *restrict @var{string}, wchar_t **restrict @var{tailptr}, int @var{base})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
The @code{wcstoumax} function is equivalent to the @code{strtoumax} function
in nearly all aspects but handles wide character strings.
@@ -2261,6 +2363,7 @@
@comment stdlib.h
@comment ISO
@deftypefun {long int} atol (const char *@var{string})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
This function is similar to the @code{strtol} function with a @var{base}
argument of @code{10}, except that it need not detect overflow errors.
The @code{atol} function is provided mostly for compatibility with
@@ -2270,6 +2373,7 @@
@comment stdlib.h
@comment ISO
@deftypefun int atoi (const char *@var{string})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
This function is like @code{atol}, except that it returns an @code{int}.
The @code{atoi} function is also considered obsolete; use @code{strtol}
instead.
@@ -2278,6 +2382,7 @@
@comment stdlib.h
@comment ISO
@deftypefun {long long int} atoll (const char *@var{string})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
This function is similar to @code{atol}, except it returns a @code{long
long int}.
@@ -2342,6 +2447,35 @@
@comment stdlib.h
@comment ISO
@deftypefun double strtod (const char *restrict @var{string}, char **restrict @var{tailptr})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
+@c Besides the unsafe-but-ruled-safe locale uses, this uses a lot of
+@c mpn, but it's all safe.
+@c
+@c round_and_return
+@c get_rounding_mode ok
+@c mpn_add_1 ok
+@c mpn_rshift ok
+@c MPN_ZERO ok
+@c MPN2FLOAT -> mpn_construct_(float|double|long_double) ok
+@c str_to_mpn
+@c mpn_mul_1 -> umul_ppmm ok
+@c mpn_add_1 ok
+@c mpn_lshift_1 -> mpn_lshift ok
+@c STRTOF_INTERNAL
+@c MPN_VAR ok
+@c SET_MANTISSA ok
+@c STRNCASECMP ok, wide and narrow
+@c round_and_return ok
+@c mpn_mul ok
+@c mpn_addmul_1 ok
+@c ... mpn_sub
+@c mpn_lshift ok
+@c udiv_qrnnd ok
+@c count_leading_zeros ok
+@c add_ssaaaa ok
+@c sub_ddmmss ok
+@c umul_ppmm ok
+@c mpn_submul_1 ok
The @code{strtod} (``string-to-double'') function converts the initial
part of @var{string} to a floating-point number, which is returned as a
value of type @code{double}.
@@ -2427,6 +2561,7 @@
@comment stdlib.h
@comment ISO
@deftypefunx {long double} strtold (const char *@var{string}, char **@var{tailptr})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
These functions are analogous to @code{strtod}, but return @code{float}
and @code{long double} values respectively. They report errors in the
same way as @code{strtod}. @code{strtof} can be substantially faster
@@ -2446,6 +2581,7 @@
@comment stdlib.h
@comment ISO
@deftypefunx {long double} wcstold (const wchar_t *@var{string}, wchar_t **@var{tailptr})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
The @code{wcstod}, @code{wcstof}, and @code{wcstol} functions are
equivalent in nearly all aspect to the @code{strtod}, @code{strtof}, and
@code{strtold} functions but it handles wide character string.
@@ -2458,6 +2594,7 @@
@comment stdlib.h
@comment ISO
@deftypefun double atof (const char *@var{string})
+@safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
This function is similar to the @code{strtod} function, except that it
need not detect overflow and underflow errors. The @code{atof} function
is provided mostly for compatibility with existing code; using
@@ -2485,6 +2622,7 @@
@comment stdlib.h
@comment SVID, Unix98
@deftypefun {char *} ecvt (double @var{value}, int @var{ndigit}, int *@var{decpt}, int *@var{neg})
+@safety{@prelim{}@mtunsafe{@mtasurace{:ecvt}}@asunsafe{}@acsafe{}}
The function @code{ecvt} converts the floating-point number @var{value}
to a string with at most @var{ndigit} decimal digits. The
returned string contains no decimal point or sign. The first digit of
@@ -2510,6 +2648,7 @@
@comment stdlib.h
@comment SVID, Unix98
@deftypefun {char *} fcvt (double @var{value}, int @var{ndigit}, int *@var{decpt}, int *@var{neg})
+@safety{@prelim{}@mtunsafe{@mtasurace{:fcvt}}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
The function @code{fcvt} is like @code{ecvt}, but @var{ndigit} specifies
the number of digits after the decimal point. If @var{ndigit} is less
than zero, @var{value} is rounded to the @math{@var{ndigit}+1}'th place to the
@@ -2528,6 +2667,9 @@
@comment stdlib.h
@comment SVID, Unix98
@deftypefun {char *} gcvt (double @var{value}, int @var{ndigit}, char *@var{buf})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
+@c gcvt calls sprintf, that ultimately calls vfprintf, which malloc()s
+@c args_value if it's too large, but gcvt never exercises this path.
@code{gcvt} is functionally equivalent to @samp{sprintf(buf, "%*g",
ndigit, value}. It is provided only for compatibility's sake. It
returns @var{buf}.
@@ -2542,6 +2684,7 @@
@comment stdlib.h
@comment GNU
@deftypefun {char *} qecvt (long double @var{value}, int @var{ndigit}, int *@var{decpt}, int *@var{neg})
+@safety{@prelim{}@mtunsafe{@mtasurace{:qecvt}}@asunsafe{}@acsafe{}}
This function is equivalent to @code{ecvt} except that it takes a
@code{long double} for the first parameter and that @var{ndigit} is
restricted by the precision of a @code{long double}.
@@ -2550,6 +2693,7 @@
@comment stdlib.h
@comment GNU
@deftypefun {char *} qfcvt (long double @var{value}, int @var{ndigit}, int *@var{decpt}, int *@var{neg})
+@safety{@prelim{}@mtunsafe{@mtasurace{:qfcvt}}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
This function is equivalent to @code{fcvt} except that it
takes a @code{long double} for the first parameter and that @var{ndigit} is
restricted by the precision of a @code{long double}.
@@ -2558,6 +2702,7 @@
@comment stdlib.h
@comment GNU
@deftypefun {char *} qgcvt (long double @var{value}, int @var{ndigit}, char *@var{buf})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This function is equivalent to @code{gcvt} except that it takes a
@code{long double} for the first parameter and that @var{ndigit} is
restricted by the precision of a @code{long double}.
@@ -2578,6 +2723,7 @@
@comment stdlib.h
@comment GNU
@deftypefun int ecvt_r (double @var{value}, int @var{ndigit}, int *@var{decpt}, int *@var{neg}, char *@var{buf}, size_t @var{len})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The @code{ecvt_r} function is the same as @code{ecvt}, except
that it places its result into the user-specified buffer pointed to by
@var{buf}, with length @var{len}. The return value is @code{-1} in
@@ -2589,6 +2735,7 @@
@comment stdlib.h
@comment SVID, Unix98
@deftypefun int fcvt_r (double @var{value}, int @var{ndigit}, int *@var{decpt}, int *@var{neg}, char *@var{buf}, size_t @var{len})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The @code{fcvt_r} function is the same as @code{fcvt}, except that it
places its result into the user-specified buffer pointed to by
@var{buf}, with length @var{len}. The return value is @code{-1} in
@@ -2600,6 +2747,7 @@
@comment stdlib.h
@comment GNU
@deftypefun int qecvt_r (long double @var{value}, int @var{ndigit}, int *@var{decpt}, int *@var{neg}, char *@var{buf}, size_t @var{len})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The @code{qecvt_r} function is the same as @code{qecvt}, except
that it places its result into the user-specified buffer pointed to by
@var{buf}, with length @var{len}. The return value is @code{-1} in
@@ -2611,6 +2759,7 @@
@comment stdlib.h
@comment GNU
@deftypefun int qfcvt_r (long double @var{value}, int @var{ndigit}, int *@var{decpt}, int *@var{neg}, char *@var{buf}, size_t @var{len})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The @code{qfcvt_r} function is the same as @code{qfcvt}, except
that it places its result into the user-specified buffer pointed to by
@var{buf}, with length @var{len}. The return value is @code{-1} in
Modified: fsf/trunk/libc/manual/conf.texi
==============================================================================
--- fsf/trunk/libc/manual/conf.texi (original)
+++ fsf/trunk/libc/manual/conf.texi Wed Jan 29 00:01:52 2014
@@ -288,6 +288,17 @@
@comment unistd.h
@comment POSIX.1
@deftypefun {long int} sysconf (int @var{parameter})
+@safety{@prelim{}@mtsafe{@mtsenv{}}@asunsafe{@asulock{} @ascuheap{}}@acunsafe{@aculock{} @acsmem{} @acsfd{}}}
+@c Some parts of the implementation open /proc and /sys files and dirs
+@c to collect system details, using fd and stream I/O depending on the
+@c case. _SC_TZNAME_MAX calls __tzname_max, that (while holding a lock)
+@c calls tzset_internal, that calls getenv if it's called the first
+@c time; there are free and strdup calls in there too. The returned max
+@c value may change over time for TZNAME_MAX, depending on selected
+@c timezones; NPROCS, NPROCS_CONF, PHYS_PAGES, AVPHYS_PAGES,
+@c NGROUPS_MAX, SIGQUEUE_MAX, depending on variable values read from
+@c /proc at each call, and from rlimit-obtained values CHILD_MAX,
+@c OPEN_MAX, ARG_MAX, SIGQUEUE_MAX.
This function is used to inquire about runtime system parameters. The
@var{parameter} argument should be one of the @samp{_SC_} symbols listed
below.
@@ -1348,6 +1359,11 @@
@comment unistd.h
@comment POSIX.1
@deftypefun {long int} pathconf (const char *@var{filename}, int @var{parameter})
+@safety{@prelim{}@mtsafe{}@asunsafe{@asulock{} @ascuheap{}}@acunsafe{@aculock{} @acsfd{} @acsmem{}}}
+@c When __statfs_link_max finds an ext* filesystem, it may read
+@c /proc/mounts or similar as a mntent stream.
+@c __statfs_chown_restricted may read from
+@c /proc/sys/fs/xfs/restrict_chown as a file descriptor.
This function is used to inquire about the limits that apply to
the file named @var{filename}.
@@ -1375,6 +1391,8 @@
@comment unistd.h
@comment POSIX.1
@deftypefun {long int} fpathconf (int @var{filedes}, int @var{parameter})
+@safety{@prelim{}@mtsafe{}@asunsafe{@asulock{} @ascuheap{}}@acunsafe{@aculock{} @acsfd{} @acsmem{}}}
+@c Same caveats as pathconf.
This is just like @code{pathconf} except that an open file descriptor
is used to specify the file for which information is requested, instead
of a file name.
@@ -1624,6 +1642,7 @@
@comment unistd.h
@comment POSIX.2
@deftypefun size_t confstr (int @var{parameter}, char *@var{buf}, size_t @var{len})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This function reads the value of a string-valued system parameter,
storing the string into @var{len} bytes of memory space starting at
@var{buf}. The @var{parameter} argument should be one of the
Modified: fsf/trunk/libc/manual/crypt.texi
==============================================================================
--- fsf/trunk/libc/manual/crypt.texi (original)
+++ fsf/trunk/libc/manual/crypt.texi Wed Jan 29 00:01:52 2014
@@ -99,6 +99,13 @@
@comment unistd.h
@comment BSD
@deftypefun {char *} getpass (const char *@var{prompt})
+@safety{@prelim{}@mtunsafe{@mtasuterm{}}@asunsafe{@ascuheap{} @asulock{} @asucorrupt{}}@acunsafe{@acuterm{} @aculock{} @acucorrupt{}}}
+@c This function will attempt to create a stream for terminal I/O, but
+@c will fallback to stdio/stderr. It attempts to change the terminal
+@c mode in a thread-unsafe way, write out the prompt, read the password,
+@c then restore the terminal mode. It has a cleanup to close the stream
+@c in case of (synchronous) cancellation, but not to restore the
+@c terminal mode.
@code{getpass} outputs @var{prompt}, then reads a string in from the
terminal without echoing it. It tries to connect to the real terminal,
@@ -134,6 +141,13 @@
@comment crypt.h
@comment BSD, SVID
@deftypefun {char *} crypt (const char *@var{key}, const char *@var{salt})
+@safety{@prelim{}@mtunsafe{@mtasurace{:crypt}}@asunsafe{@asucorrupt{} @asulock{} @ascuheap{} @ascudlopen{}}@acunsafe{@aculock{} @acsmem{}}}
+@c Besides the obvious problem of returning a pointer into static
+@c storage, the DES initializer takes an internal lock with the usual
+@c set of problems for AS- and AC-Safety. The FIPS mode checker and the
+@c NSS implementations of may leak file descriptors if canceled. The
+@c The MD5, SHA256 and SHA512 implementations will malloc on long keys,
+@c and NSS relies on dlopening, which brings about another can of worms.
The @code{crypt} function takes a password, @var{key}, as a string, and
a @var{salt} character array which is described below, and returns a
@@ -195,6 +209,9 @@
@comment crypt.h
@comment GNU
@deftypefun {char *} crypt_r (const char *@var{key}, const char *@var{salt}, {struct crypt_data *} @var{data})
+@safety{@prelim{}@mtsafe{}@asunsafe{@asucorrupt{} @asulock{} @ascuheap{} @ascudlopen{}}@acunsafe{@aculock{} @acsmem{}}}
+@c Compared with crypt, this function fixes the @mtasurace:crypt
+@c problem, but nothing else.
The @code{crypt_r} function does the same thing as @code{crypt}, but
takes an extra parameter which includes space for its result (among
@@ -241,6 +258,11 @@
@comment crypt.h
@comment BSD, SVID
@deftypefun void setkey (const char *@var{key})
+@safety{@prelim{}@mtunsafe{@mtasurace{:crypt}}@asunsafe{@asucorrupt{} @asulock{}}@acunsafe{@aculock{}}}
+@c The static buffer stores the key, making it fundamentally
+@c thread-unsafe. The locking issues are only in the initialization
+@c path; cancelling the initialization will leave the lock held, it
+@c would otherwise repeat the initialization on the next call.
The @code{setkey} function sets an internal data structure to be an
expanded form of @var{key}. @var{key} is specified as an array of 64
@@ -252,6 +274,8 @@
@comment crypt.h
@comment BSD, SVID
@deftypefun void encrypt (char *@var{block}, int @var{edflag})
+@safety{@prelim{}@mtunsafe{@mtasurace{:crypt}}@asunsafe{@asucorrupt{} @asulock{}}@acunsafe{@aculock{}}}
+@c Same issues as setkey.
The @code{encrypt} function encrypts @var{block} if
@var{edflag} is 0, otherwise it decrypts @var{block}, using a key
@@ -265,9 +289,11 @@
@comment crypt.h
@comment GNU
@deftypefun void setkey_r (const char *@var{key}, {struct crypt_data *} @var{data})
+@c @safety{@prelim{}@mtsafe{}@asunsafe{@asucorrupt{} @asulock{}}@acunsafe{@aculock{}}}
@comment crypt.h
@comment GNU
@deftypefunx void encrypt_r (char *@var{block}, int @var{edflag}, {struct crypt_data *} @var{data})
+@safety{@prelim{}@mtsafe{}@asunsafe{@asucorrupt{} @asulock{}}@acunsafe{@aculock{}}}
These are reentrant versions of @code{setkey} and @code{encrypt}. The
only difference is the extra parameter, which stores the expanded
@@ -282,6 +308,7 @@
@comment rpc/des_crypt.h
@comment SUNRPC
@deftypefun int ecb_crypt (char *@var{key}, char *@var{blocks}, unsigned @var{len}, unsigned @var{mode})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The function @code{ecb_crypt} encrypts or decrypts one or more blocks
using DES. Each block is encrypted independently.
@@ -356,6 +383,7 @@
@comment rpc/des_crypt.h
@comment SUNRPC
@deftypefun int DES_FAILED (int @var{err})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This macro returns 1 if @var{err} is a `success' result code from
@code{ecb_crypt} or @code{cbc_crypt}, and 0 otherwise.
@end deftypefun
@@ -363,6 +391,7 @@
@comment rpc/des_crypt.h
@comment SUNRPC
@deftypefun int cbc_crypt (char *@var{key}, char *@var{blocks}, unsigned @var{len}, unsigned @var{mode}, char *@var{ivec})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The function @code{cbc_crypt} encrypts or decrypts one or more blocks
using DES in Cipher Block Chaining mode.
@@ -389,6 +418,7 @@
@comment rpc/des_crypt.h
@comment SUNRPC
@deftypefun void des_setparity (char *@var{key})
+@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
The function @code{des_setparity} changes the 64-bit @var{key}, stored
packed in 8-bit bytes, to have odd parity by altering the low bits of
Modified: fsf/trunk/libc/manual/intro.texi
==============================================================================
--- fsf/trunk/libc/manual/intro.texi (original)
+++ fsf/trunk/libc/manual/intro.texi Wed Jan 29 00:01:52 2014
@@ -158,6 +158,14 @@
Utilities standard} (POSIX.2) are also implemented in @theglibc{}.
These include utilities for dealing with regular expressions and other
pattern matching facilities (@pxref{Pattern Matching}).
+
+@menu
+* POSIX Safety Concepts:: Safety concepts from POSIX.
+* Unsafe Features:: Features that make functions unsafe.
+* Conditionally Safe Features:: Features that make functions unsafe
+ in the absence of workarounds.
+* Other Safety Remarks:: Additional safety features and remarks.
+@end menu
@comment Roland sez:
@comment The GNU C library as it stands conforms to 1003.2 draft 11, which
@@ -172,6 +180,683 @@
@comment <wordexp.h> (not yet implemented)
@comment confstr
+@node POSIX Safety Concepts, Unsafe Features, , POSIX
+@subsubsection POSIX Safety Concepts
+@cindex POSIX Safety Concepts
+
+This manual documents various safety properties of @glibcadj{}
+functions, in lines that follow their prototypes and look like:
+
+@sampsafety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
+
+The properties are assessed according to the criteria set forth in the
+POSIX standard for such safety contexts as Thread-, Async-Signal- and
+Async-Cancel- -Safety. Intuitive definitions of these properties,
+attempting to capture the meaning of the standard definitions, follow.
+
+@itemize @bullet
+
+@item
+@cindex MT-Safe
+@cindex Thread-Safe
+@code{MT-Safe} or Thread-Safe functions are safe to call in the presence
+of other threads. MT, in MT-Safe, stands for Multi Thread.
+
+Being MT-Safe does not imply a function is atomic, nor that it uses any
+of the memory synchronization mechanisms POSIX exposes to users. It is
+even possible that calling MT-Safe functions in sequence does not yield
+an MT-Safe combination. For example, having a thread call two MT-Safe
+functions one right after the other does not guarantee behavior
+equivalent to atomic execution of a combination of both functions, since
+concurrent calls in other threads may interfere in a destructive way.
+
+Whole-program optimizations that could inline functions across library
+interfaces may expose unsafe reordering, and so performing inlining
+across the @glibcadj{} interface is not recommended. The documented
+MT-Safety status is not guaranteed under whole-program optimization.
+However, functions defined in user-visible headers are designed to be
+safe for inlining.
+
+
+@item
+@cindex AS-Safe
+@cindex Async-Signal-Safe
+@code{AS-Safe} or Async-Signal-Safe functions are safe to call from
+asynchronous signal handlers. AS, in AS-Safe, stands for Asynchronous
+Signal.
+
+Many functions that are AS-Safe may set @code{errno}, or modify the
+floating-point environment, because their doing so does not make them
+unsuitable for use in signal handlers. However, programs could
+misbehave should asynchronous signal handlers modify this thread-local
+state, and the signal handling machinery cannot be counted on to
+preserve it. Therefore, signal handlers that call functions that may
+set @code{errno} or modify the floating-point environment @emph{must}
+save their original values, and restore them before returning.
+
+
+@item
+@cindex AC-Safe
+@cindex Async-Cancel-Safe
+@code{AC-Safe} or Async-Cancel-Safe functions are safe to call when
+asynchronous cancellation is enabled. AC in AC-Safe stands for
+Asynchronous Cancellation.
+
+The POSIX standard defines only three functions to be AC-Safe, namely
+@code{pthread_cancel}, @code{pthread_setcancelstate}, and
+@code{pthread_setcanceltype}. At present @theglibc{} provides no
+guarantees beyond these three functions, but does document which
+functions are presently AC-Safe. This documentation is provided for use
+by @theglibc{} developers.
+
+Just like signal handlers, cancellation cleanup routines must configure
+the floating point environment they require. The routines cannot assume
+a floating point environment, particularly when asynchronous
+cancellation is enabled. If the configuration of the floating point
+environment cannot be performed atomically then it is also possible that
+the environment encountered is internally inconsistent.
+
+
+@item
+@cindex MT-Unsafe
+@cindex Thread-Unsafe
+@cindex AS-Unsafe
+@cindex Async-Signal-Unsafe
+@cindex AC-Unsafe
+@cindex Async-Cancel-Unsafe
+@code{MT-Unsafe}, @code{AS-Unsafe}, @code{AC-Unsafe} functions are not
+safe to call within the safety contexts described above. Calling them
+within such contexts invokes undefined behavior.
+
+Functions not explicitly documented as safe in a safety context should
+be regarded as Unsafe.
+
+
+@item
+@cindex Preliminary
+@code{Preliminary} safety properties are documented, indicating these
+properties may @emph{not} be counted on in future releases of
+@theglibc{}.
+
+Such preliminary properties are the result of an assessment of the
+properties of our current implementation, rather than of what is
+mandated and permitted by current and future standards.
+
+Although we strive to abide by the standards, in some cases our
+implementation is safe even when the standard does not demand safety,
+and in other cases our implementation does not meet the standard safety
+requirements. The latter are most likely bugs; the former, when marked
+as @code{Preliminary}, should not be counted on: future standards may
+require changes that are not compatible with the additional safety
+properties afforded by the current implementation.
+
+Furthermore, the POSIX standard does not offer a detailed definition of
+safety. We assume that, by ``safe to call'', POSIX means that, as long
+as the program does not invoke undefined behavior, the ``safe to call''
+function behaves as specified, and does not cause other functions to
+deviate from their specified behavior. We have chosen to use its loose
+definitions of safety, not because they are the best definitions to use,
+but because choosing them harmonizes this manual with POSIX.
+
+Please keep in mind that these are preliminary definitions and
+annotations, and certain aspects of the definitions are still under
+discussion and might be subject to clarification or change.
+
+Over time, we envision evolving the preliminary safety notes into stable
+commitments, as stable as those of our interfaces. As we do, we will
+remove the @code{Preliminary} keyword from safety notes. As long as the
+keyword remains, however, they are not to be regarded as a promise of
+future behavior.
+
+
+@end itemize
+
+Other keywords that appear in safety notes are defined in subsequent
+sections.
+
+
+@node Unsafe Features, Conditionally Safe Features, POSIX Safety Concepts, POSIX
+@subsubsection Unsafe Features
+@cindex Unsafe Features
+
+Functions that are unsafe to call in certain contexts are annotated with
+keywords that document their features that make them unsafe to call.
+AS-Unsafe features in this section indicate the functions are never safe
+to call when asynchronous signals are enabled. AC-Unsafe features
+indicate they are never safe to call when asynchronous cancellation is
+enabled. There are no MT-Unsafe marks in this section.
+
+@itemize @bullet
+
+@item @code{lock}
+@cindex lock
+
+Functions marked with @code{lock} as an AS-Unsafe feature may be
+interrupted by a signal while holding a non-recursive lock. If the
+signal handler calls another such function that takes the same lock, the
+result is a deadlock.
+
+Functions annotated with @code{lock} as an AC-Unsafe feature may, if
+cancelled asynchronously, fail to release a lock that would have been
+released if their execution had not been interrupted by asynchronous
+thread cancellation. Once a lock is left taken, attempts to take that
+lock will block indefinitely.
+
+
+@item @code{corrupt}
+@cindex corrupt
+
+Functions marked with @code{corrupt} as an AS-Unsafe feature may corrupt
+data structures and misbehave when they interrupt, or are interrupted
+by, another such function. Unlike functions marked with @code{lock},
+these take recursive locks to avoid MT-Safety problems, but this is not
+enough to stop a signal handler from observing a partially-updated data
+structure. Further corruption may arise from the interrupted function's
+failure to notice updates made by signal handlers.
+
+Functions marked with @code{corrupt} as an AC-Unsafe feature may leave
+data structures in a corrupt, partially updated state. Subsequent uses
+of the data structure may misbehave.
+
+@c A special case, probably not worth documenting separately, involves
+@c reallocing, or even freeing pointers. Any case involving free could
+@c be easily turned into an ac-safe leak by resetting the pointer before
+@c releasing it; I don't think we have any case that calls for this sort
+@c of fixing. Fixing the realloc cases would require a new interface:
+@c instead of @code{ptr=realloc(ptr,size)} we'd have to introduce
+@c @code{acsafe_realloc(&ptr,size)} that would modify ptr before
+@c releasing the old memory. The ac-unsafe realloc could be implemented
+@c in terms of an internal interface with this semantics (say
+@c __acsafe_realloc), but since realloc can be overridden, the function
+@c we call to implement realloc should not be this internal interface,
+@c but another internal interface that calls __acsafe_realloc if realloc
+@c was not overridden, and calls the overridden realloc with async
+@c cancel disabled. --lxoliva
+
+
+@item @code{heap}
+@cindex heap
+
+Functions marked with @code{heap} may call heap memory management
+functions from the @code{malloc}/@code{free} family of functions and are
+only as safe as those functions. This note is thus equivalent to:
+
+@sampsafety{@asunsafe{@asulock{}}@acunsafe{@aculock{} @acsfd{} @acsmem{}}}
+
+
+@c Check for cases that should have used plugin instead of or in
+@c addition to this. Then, after rechecking gettext, adjust i18n if
+@c needed.
+@item @code{dlopen}
+@cindex dlopen
+
+Functions marked with @code{dlopen} use the dynamic loader to load
+shared libraries into the current execution image. This involves
+opening files, mapping them into memory, allocating additional memory,
+resolving symbols, applying relocations and more, all of this while
+holding internal dynamic loader locks.
+
+The locks are enough for these functions to be AS- and AC-Unsafe, but
+other issues may arise. At present this is a placeholder for all
+potential safety issues raised by @code{dlopen}.
+
+@c dlopen runs init and fini sections of the module; does this mean
+@c dlopen always implies plugin?
+
+
+@item @code{plugin}
+@cindex plugin
+
+Functions annotated with @code{plugin} may run code from plugins that
+may be external to @theglibc{}. Such plugin functions are assumed to be
+MT-Safe, AS-Unsafe and AC-Unsafe. Examples of such plugins are stack
+@cindex NSS
+unwinding libraries, name service switch (NSS) and character set
+@cindex iconv
+conversion (iconv) back-ends.
+
+Although the plugins mentioned as examples are all brought in by means
+of dlopen, the @code{plugin} keyword does not imply any direct
+involvement of the dynamic loader or the @code{libdl} interfaces, those
+are covered by @code{dlopen}. For example, if one function loads a
+module and finds the addresses of some of its functions, while another
+just calls those already-resolved functions, the former will be marked
+with @code{dlopen}, whereas the latter will get the @code{plugin}. When
+a single function takes all of these actions, then it gets both marks.
+
+
+@item @code{i18n}
+@cindex i18n
+
+Functions marked with @code{i18n} may call internationalization
+functions of the @code{gettext} family and will be only as safe as those
+functions. This note is thus equivalent to:
+
+@sampsafety{@mtsafe{@mtsenv{}}@asunsafe{@asucorrupt{} @ascuheap{} @ascudlopen{}}@acunsafe{@acucorrupt{}}}
+
+
+@item @code{timer}
+@cindex timer
+
+Functions marked with @code{timer} use the @code{alarm} function or
+similar to set a time-out for a system call or a long-running operation.
+In a multi-threaded program, there is a risk that the time-out signal
+will be delivered to a different thread, thus failing to interrupt the
+intended thread. Besides being MT-Unsafe, such functions are always
+AS-Unsafe, because calling them in signal handlers may interfere with
+timers set in the interrupted code, and AC-Unsafe, because there is no
+safe way to guarantee an earlier timer will be reset in case of
+asynchronous cancellation.
+
+@end itemize
+
+
+@node Conditionally Safe Features, Other Safety Remarks, Unsafe Features, POSIX
+@subsubsection Conditionally Safe Features
+@cindex Conditionally Safe Features
+
+For some features that make functions unsafe to call in certain
+contexts, there are known ways to avoid the safety problem other than
+refraining from calling the function altogether. The keywords that
+follow refer to such features, and each of their definitions indicate
+how the whole program needs to be constrained in order to remove the
+safety problem indicated by the keyword. Only when all the reasons that
+make a function unsafe are observed and addressed, by applying the
+documented constraints, does the function become safe to call in a
+context.
+
+@itemize @bullet
+
+@item @code{init}
+@cindex init
+
+Functions marked with @code{init} as an MT-Unsafe feature perform
+MT-Unsafe initialization when they are first called.
+
+Calling such a function at least once in single-threaded mode removes
+this specific cause for the function to be regarded as MT-Unsafe. If no
+other cause for that remains, the function can then be safely called
+after other threads are started.
+
+Functions marked with @code{init} as an AS- or AC-Unsafe feature use the
+internal @code{libc_once} machinery or similar to initialize internal
+data structures.
+
+If a signal handler interrupts such an initializer, and calls any
+function that also performs @code{libc_once} initialization, it will
+deadlock if the thread library has been loaded.
+
+Furthermore, if an initializer is partially complete before it is
+canceled or interrupted by a signal whose handler requires the same
+initialization, some or all of the initialization may be performed more
+than once, leaking resources or even resulting in corrupt internal data.
+
+Applications that need to call functions marked with @code{init} as an
+AS- or AC-Unsafe feature should ensure the initialization is performed
+before configuring signal handlers or enabling cancellation, so that the
+AS- and AC-Safety issues related with @code{libc_once} do not arise.
+
+@c We may have to extend the annotations to cover conditions in which
+@c initialization may or may not occur, since an initial call in a safe
+@c context is no use if the initialization doesn't take place at that
+@c time: it doesn't remove the risk for later calls.
+
+
+@item @code{race}
+@cindex race
+
+Functions annotated with @code{race} as an MT-Safety issue operate on
+objects in ways that may cause data races or similar forms of
+destructive interference out of concurrent execution. In some cases,
+the objects are passed to the functions by users; in others, they are
+used by the functions to return values to users; in others, they are not
+even exposed to users.
+
+We consider access to objects passed as (indirect) arguments to
+functions to be data race free. The assurance of data race free objects
+is the caller's responsibility. We will not mark a function as
+MT-Unsafe or AS-Unsafe if it misbehaves when users fail to take the
+measures required by POSIX to avoid data races when dealing with such
+objects. As a general rule, if a function is documented as reading from
+an object passed (by reference) to it, or modifying it, users ought to
+use memory synchronization primitives to avoid data races just as they
+would should they perform the accesses themselves rather than by calling
+the library function. @code{FILE} streams are the exception to the
+general rule, in that POSIX mandates the library to guard against data
+races in many functions that manipulate objects of this specific opaque
+type. We regard this as a convenience provided to users, rather than as
+a general requirement whose expectations should extend to other types.
+
+In order to remind users that guarding certain arguments is their
+responsibility, we will annotate functions that take objects of certain
+types as arguments. We draw the line for objects passed by users as
+follows: objects whose types are exposed to users, and that users are
+expected to access directly, such as memory buffers, strings, and
+various user-visible @code{struct} types, do @emph{not} give reason for
+functions to be annotated with @code{race}. It would be noisy and
+redundant with the general requirement, and not many would be surprised
+by the library's lack of internal guards when accessing objects that can
+be accessed directly by users.
+
+As for objects that are opaque or opaque-like, in that they are to be
+manipulated only by passing them to library functions (e.g.,
+@code{FILE}, @code{DIR}, @code{obstack}, @code{iconv_t}), there might be
+additional expectations as to internal coordination of access by the
+library. We will annotate, with @code{race} followed by a colon and the
+argument name, functions that take such objects but that do not take
+care of synchronizing access to them by default. For example,
+@code{FILE} stream @code{unlocked} functions will be annotated, but
+those that perform implicit locking on @code{FILE} streams by default
+will not, even though the implicit locking may be disabled on a
+per-stream basis.
+
+In either case, we will not regard as MT-Unsafe functions that may
+access user-supplied objects in unsafe ways should users fail to ensure
+the accesses are well defined. The notion prevails that users are
+expected to safeguard against data races any user-supplied objects that
+the library accesses on their behalf.
+
+@c The above describes @mtsrace; @mtasurace is described below.
+
+This user responsibility does not apply, however, to objects controlled
+by the library itself, such as internal objects and static buffers used
+to return values from certain calls. When the library doesn't guard
+them against concurrent uses, these cases are regarded as MT-Unsafe and
+AS-Unsafe (although the @code{race} mark under AS-Unsafe will be omitted
+as redundant with the one under MT-Unsafe). As in the case of
+user-exposed objects, the mark may be followed by a colon and an
+identifier. The identifier groups all functions that operate on a
+certain unguarded object; users may avoid the MT-Safety issues related
+with unguarded concurrent access to such internal objects by creating a
+non-recursive mutex related with the identifier, and always holding the
+mutex when calling any function marked as racy on that identifier, as
+they would have to should the identifier be an object under user
+control. The non-recursive mutex avoids the MT-Safety issue, but it
+trades one AS-Safety issue for another, so use in asynchronous signals
+remains undefined.
+
+When the identifier relates to a static buffer used to hold return
+values, the mutex must be held for as long as the buffer remains in use
+by the caller. Many functions that return pointers to static buffers
+offer reentrant variants that store return values in caller-supplied
+buffers instead. In some cases, such as @code{tmpname}, the variant is
+chosen not by calling an alternate entry point, but by passing a
+non-@code{NULL} pointer to the buffer in which the returned values are
+to be stored. These variants are generally preferable in multi-threaded
+programs, although some of them are not MT-Safe because of other
+internal buffers, also documented with @code{race} notes.
+
+
+@item @code{const}
+@cindex const
+
+Functions marked with @code{const} as an MT-Safety issue non-atomically
+modify internal objects that are better regarded as constant, because a
+substantial portion of @theglibc{} accesses them without
+synchronization. Unlike @code{race}, that causes both readers and
+writers of internal objects to be regarded as MT-Unsafe and AS-Unsafe,
+this mark is applied to writers only. Writers remain equally MT- and
+AS-Unsafe to call, but the then-mandatory constness of objects they
+modify enables readers to be regarded as MT-Safe and AS-Safe (as long as
+no other reasons for them to be unsafe remain), since the lack of
+synchronization is not a problem when the objects are effectively
+constant.
+
+The identifier that follows the @code{const} mark will appear by itself
+as a safety note in readers. Programs that wish to work around this
+safety issue, so as to call writers, may use a non-recursve
+@code{rwlock} associated with the identifier, and guard @emph{all} calls
+to functions marked with @code{const} followed by the identifier with a
+write lock, and @emph{all} calls to functions marked with the identifier
+by itself with a read lock. The non-recursive locking removes the
+MT-Safety problem, but it trades one AS-Safety problem for another, so
+use in asynchronous signals remains undefined.
+
+@c But what if, instead of marking modifiers with const:id and readers
+@c with just id, we marked writers with race:id and readers with ro:id?
+@c Instead of having to define each instance of ÃÂÂidÃÂÂ, we'd have a
+@c general pattern governing all such ÃÂÂidÃÂÂs, wherein race:id would
+@c suggest the need for an exclusive/write lock to make the function
+@c safe, whereas ro:id would indicate ÃÂÂidÃÂÂ is expected to be read-only,
+@c but if any modifiers are called (while holding an exclusive lock),
+@c then ro:id-marked functions ought to be guarded with a read lock for
+@c safe operation. ro:env or ro:locale, for example, seems to convey
+@c more clearly the expectations and the meaning, than just env or
+@c locale.
+
+
+@item @code{sig}
+@cindex sig
+
+Functions marked with @code{sig} as a MT-Safety issue (that implies an
+identical AS-Safety issue, omitted for brevity) may temporarily install
+a signal handler for internal purposes, which may interfere with other
+uses of the signal, identified after a colon.
+
+This safety problem can be worked around by ensuring that no other uses
+of the signal will take place for the duration of the call. Holding a
+non-recursive mutex while calling all functions that use the same
+temporary signal; blocking that signal before the call and resetting its
+handler afterwards is recommended.
+
+There is no safe way to guarantee the original signal handler is
+restored in case of asynchronous cancellation, therefore so-marked
+functions are also AC-Unsafe.
+
+@c fixme: at least deferred cancellation should get it right, and would
+@c obviate the restoring bit below, and the qualifier above.
+
+Besides the measures recommended to work around the MT- and AS-Safety
+problem, in order to avert the cancellation problem, disabling
+asynchronous cancellation @emph{and} installing a cleanup handler to
+restore the signal to the desired state and to release the mutex are
+recommended.
+
+
+@item @code{term}
+@cindex term
+
+Functions marked with @code{term} as an MT-Safety issue may change the
+terminal settings in the recommended way, namely: call @code{tcgetattr},
+modify some flags, and then call @code{tcsetattr}; this creates a window
+in which changes made by other threads are lost. Thus, functions marked
+with @code{term} are MT-Unsafe. The same window enables changes made by
+asynchronous signals to be lost. These functions are also AS-Unsafe,
+but the corresponding mark is omitted as redundant.
+
+It is thus advisable for applications using the terminal to avoid
+concurrent and reentrant interactions with it, by not using it in signal
+handlers or blocking signals that might use it, and holding a lock while
+calling these functions and interacting with the terminal. This lock
+should also be used for mutual exclusion with functions marked with
+@code{@mtasurace{:tcattr}}.
+
+Functions marked with @code{term} as an AC-Safety issue are supposed to
+restore terminal settings to their original state, after temporarily
+changing them, but they may fail to do so if cancelled.
+
+@c fixme: at least deferred cancellation should get it right, and would
+@c obviate the restoring bit below, and the qualifier above.
+
+Besides the measures recommended to work around the MT- and AS-Safety
+problem, in order to avert the cancellation problem, disabling
+asynchronous cancellation @emph{and} installing a cleanup handler to
+restore the terminal settings to the original state and to release the
+mutex are recommended.
+
+
+@end itemize
+
+
+@node Other Safety Remarks, , Conditionally Safe Features, POSIX
+@subsubsection Other Safety Remarks
+@cindex Other Safety Remarks
+
+Additional keywords may be attached to functions, indicating features
+that do not make a function unsafe to call, but that may need to be
+taken into account in certain classes of programs:
+
+@itemize @bullet
+
+@c revisit: uses are mt-safe, distinguish from const:locale
+@item @code{locale}
+@cindex locale
+
+Functions annotated with @code{locale} as an MT-Safety issue read from
+the locale object without any form of synchronization. Functions
+annotated with @code{locale} called concurrently with locale changes may
+behave in ways that do not correspond to any of the locales active
+during their execution, but an unpredictable mix thereof.
+
+We do not mark these functions as MT- or AS-Unsafe, however, because
+functions that modify the locale object are marked with
+@code{const:locale} and regarded as unsafe. Being unsafe, the latter
+are not to be called when multiple threads are running or asynchronous
+signals are enabled, and so the locale can be considered effectively
+constant in these contexts, which makes the former safe.
+
+@c Should the locking strategy suggested under @code{const} be used,
+@c failure to guard locale uses is not as fatal as data races in
+@c general: unguarded uses will @emph{not} follow dangling pointers or
+@c access uninitialized, unmapped or recycled memory. Each access will
+@c read from a consistent locale object that is or was active at some
+@c point during its execution. Without synchronization, however, it
+@c cannot even be assumed that, after a change in locale, earlier
+@c locales will no longer be used, even after the newly-chosen one is
+@c used in the thread. Nevertheless, even though unguarded reads from
+@c the locale will not violate type safety, functions that access the
+@c locale multiple times may invoke all sorts of undefined behavior
+@c because of the unexpected locale changes.
+
+
+@c revisit: this was incorrectly used as an mt-unsafe marker.
+@item @code{env}
+@cindex env
+
+Functions marked with @code{env} as an MT-Safety issue access the
+environment with @code{getenv} or similar, without any guards to ensure
+safety in the presence of concurrent modifications.
+
+We do not mark these functions as MT- or AS-Unsafe, however, because
+functions that modify the environment are all marked with
+@code{const:env} and regarded as unsafe. Being unsafe, the latter are
+not to be called when multiple threads are running or asynchronous
+signals are enabled, and so the environment can be considered
+effectively constant in these contexts, which makes the former safe.
+
+
+@item @code{hostid}
+@cindex hostid
+
+The function marked with @code{hostid} as an MT-Safety issue reads from
+the system-wide data structures that hold the ``host ID'' of the
+machine. These data structures cannot generally be modified atomically.
+Since it is expected that the ``host ID'' will not normally change, the
+function that reads from it (@code{gethostid}) is regarded as safe,
+whereas the function that modifies it (@code{sethostid}) is marked with
+@code{@mtasuconst{:@mtshostid{}}}, indicating it may require special
+care if it is to be called. In this specific case, the special care
+amounts to system-wide (not merely intra-process) coordination.
+
+
+@item @code{sigintr}
+@cindex sigintr
+
+Functions marked with @code{sigintr} as an MT-Safety issue access the
+@code{_sigintr} internal data structure without any guards to ensure
+safety in the presence of concurrent modifications.
+
+We do not mark these functions as MT- or AS-Unsafe, however, because
+functions that modify the this data structure are all marked with
+@code{const:sigintr} and regarded as unsafe. Being unsafe, the latter
+are not to be called when multiple threads are running or asynchronous
+signals are enabled, and so the data structure can be considered
+effectively constant in these contexts, which makes the former safe.
+
+
+@item @code{fd}
+@cindex fd
+
+Functions annotated with @code{fd} as an AC-Safety issue may leak file
+descriptors if asynchronous thread cancellation interrupts their
+execution.
+
+Functions that allocate or deallocate file descriptors will generally be
+marked as such. Even if they attempted to protect the file descriptor
+allocation and deallocation with cleanup regions, allocating a new
+descriptor and storing its number where the cleanup region could release
+it cannot be performed as a single atomic operation. Similarly,
+releasing the descriptor and taking it out of the data structure
+normally responsible for releasing it cannot be performed atomically.
+There will always be a window in which the descriptor cannot be released
+because it was not stored in the cleanup handler argument yet, or it was
+already taken out before releasing it. It cannot be taken out after
+release: an open descriptor could mean either that the descriptor still
+has to be closed, or that it already did so but the descriptor was
+reallocated by another thread or signal handler.
+
+Such leaks could be internally avoided, with some performance penalty,
+by temporarily disabling asynchronous thread cancellation. However,
+since callers of allocation or deallocation functions would have to do
+this themselves, to avoid the same sort of leak in their own layer, it
+makes more sense for the library to assume they are taking care of it
+than to impose a performance penalty that is redundant when the problem
+is solved in upper layers, and insufficient when it is not.
+
+This remark by itself does not cause a function to be regarded as
+AC-Unsafe. However, cumulative effects of such leaks may pose a
+problem for some programs. If this is the case, suspending asynchronous
+cancellation for the duration of calls to such functions is recommended.
+
+
+@item @code{mem}
+@cindex mem
+
+Functions annotated with @code{mem} as an AC-Safety issue may leak
+memory if asynchronous thread cancellation interrupts their execution.
+
+The problem is similar to that of file descriptors: there is no atomic
+interface to allocate memory and store its address in the argument to a
+cleanup handler, or to release it and remove its address from that
+argument, without at least temporarily disabling asynchronous
+cancellation, which these functions do not do.
+
+This remark does not by itself cause a function to be regarded as
+generally AC-Unsafe. However, cumulative effects of such leaks may be
+severe enough for some programs that disabling asynchronous cancellation
+for the duration of calls to such functions may be required.
+
+
+@item @code{cwd}
+@cindex cwd
+
+Functions marked with @code{cwd} as an MT-Safety issue may temporarily
+change the current working directory during their execution, which may
+cause relative pathnames to be resolved in unexpected ways in other
+threads or within asynchronous signal or cancellation handlers.
+
+This is not enough of a reason to mark so-marked functions as MT- or
+AS-Unsafe, but when this behavior is optional (e.g., @code{nftw} with
+@code{FTW_CHDIR}), avoiding the option may be a good alternative to
+using full pathnames or file descriptor-relative (e.g. @code{openat})
+system calls.
+
+
+@item @code{!posix}
+@cindex !posix
+
+This remark, as an MT-, AS- or AC-Safety note to a function, indicates
+the safety status of the function is known to differ from the specified
+status in the POSIX standard. For example, POSIX does not require a
+function to be Safe, but our implementation is, or vice-versa.
+
+For the time being, the absence of this remark does not imply the safety
+properties we documented are identical to those mandated by POSIX for
+the corresponding functions.
+
+
+@end itemize
+
@node Berkeley Unix, SVID, POSIX, Standards and Portability
@subsection Berkeley Unix
Modified: fsf/trunk/libc/manual/macros.texi
==============================================================================
--- fsf/trunk/libc/manual/macros.texi (original)
+++ fsf/trunk/libc/manual/macros.texi Wed Jan 29 00:01:52 2014
@@ -47,4 +47,169 @@
GNU/Linux systems
@end macro
+@c Document the safety functions as preliminary. It does NOT expand its
+@c comments.
+@macro prelim {comments}
+Preliminary:
+
+@end macro
+@c Document a function as thread safe.
+@macro mtsafe {comments}
+| MT-Safe \comments\
+
+@end macro
+@c Document a function as thread unsafe.
+@macro mtunsafe {comments}
+| MT-Unsafe \comments\
+
+@end macro
+@c Document a function as safe for use in asynchronous signal handlers.
+@macro assafe {comments}
+| AS-Safe \comments\
+
+@end macro
+@c Document a function as unsafe for use in asynchronous signal
+@c handlers. This distinguishes unmarked functions, for which this
+@c property has not been assessed, from those that have been analyzed.
+@macro asunsafe {comments}
+| AS-Unsafe \comments\
+
+@end macro
+@c Document a function as safe for use when asynchronous cancellation is
+@c enabled.
+@macro acsafe {comments}
+| AC-Safe \comments\
+
+@end macro
+@c Document a function as unsafe for use when asynchronous cancellation
+@c is enabled. This distinguishes unmarked functions, for which this
+@c property has not been assessed, from those that have been analyzed.
+@macro acunsafe {comments}
+| AC-Unsafe \comments\
+
+@end macro
+@c Format safety properties without referencing the section of the
+@c definitions. To be used in the definitions of the properties
+@c themselves.
+@macro sampsafety {notes}
+@noindent
+\notes\|
+
+
+@end macro
+@c Format the safety properties of a function.
+@macro safety {notes}
+\notes\| @xref{POSIX Safety Concepts}.
+
+
+@end macro
+@macro mtasurace {comments}
+race\comments\
+@end macro
+@macro asurace {comments}
+race\comments\
+@end macro
+@macro mtsrace {comments}
+race\comments\
+@end macro
+@macro mtasuconst {comments}
+const\comments\
+@end macro
+@macro mtslocale {comments}
+locale\comments\
+@end macro
+@macro mtsenv {comments}
+env\comments\
+@end macro
+@macro mtshostid {comments}
+hostid\comments\
+@end macro
+@macro mtssigintr {comments}
+sigintr\comments\
+@end macro
+@macro mtuinit {comments}
+init\comments\
+@end macro
+@macro asuinit {comments}
+init\comments\
+@end macro
+@macro acuinit {comments}
+init\comments\
+@end macro
+@macro asulock {comments}
+lock\comments\
+@end macro
+@macro aculock {comments}
+lock\comments\
+@end macro
+@macro asucorrupt {comments}
+corrupt\comments\
+@end macro
+@macro acucorrupt {comments}
+corrupt\comments\
+@end macro
+@macro ascuheap {comments}
+heap\comments\
+@end macro
+@macro asuheap {comments}
+heap\comments\
+@end macro
+@macro ascudlopen {comments}
+dlopen\comments\
+@end macro
+@macro ascuplugin {comments}
+plugin\comments\
+@end macro
+@macro ascuintl {comments}
+i18n\comments\
+@end macro
+@macro asuintl {comments}
+i18n\comments\
+@end macro
+@macro acsfd {comments}
+fd\comments\
+@end macro
+@macro acsmem {comments}
+mem\comments\
+@end macro
+@macro mtascusig {comments}
+sig\comments\
+@end macro
+@macro mtasuterm {comments}
+term\comments\
+@end macro
+@macro acuterm {comments}
+term\comments\
+@end macro
+@macro mtstimer {comments}
+timer\comments\
+@end macro
+@macro mtascutimer {comments}
+timer\comments\
+@end macro
+@macro mtasscwd {comments}
+cwd\comments\
+@end macro
+@macro acscwd {comments}
+cwd\comments\
+@end macro
+@macro mtsposix {comments}
+!posix\comments\
+@end macro
+@macro mtuposix {comments}
+!posix\comments\
+@end macro
+@macro assposix {comments}
+!posix\comments\
+@end macro
+@macro asuposix {comments}
+!posix\comments\
+@end macro
+@macro acsposix {comments}
+!posix\comments\
+@end macro
+@macro acuposix {comments}
+!posix\comments\
+@end macro
+
@end ifclear
_______________________________________________
Commits mailing list
Commits@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/commits