-.\" Copyright (c) 2014, Red Hat, Inc.
+.\" Copyright (c) 2014, Red Hat, Inc
+.\" Written by Alexandre Oliva <aoliva@redhat.com>
.\"
.\" %%%LICENSE_START(GPLv2+_DOC_FULL)
.\" This is free documentation; you can redistribute it and/or
.\" License along with this manual; if not, see
.\" <http://www.gnu.org/licenses/>.
.\" %%%LICENSE_END
-.TH ATTRIBUTES 7 2014-10-16 "Linux" "Linux Programmer's Manual"
+.TH ATTRIBUTES 7 2015-03-02 "Linux" "Linux Programmer's Manual"
.SH NAME
attributes \- POSIX safety concepts
.SH DESCRIPTION
.\"
.\"
-.SS POSIX safety concepts
-This manual documents various safety properties of GNU C Library
-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-Safety, Async-Signal-Safety and Async-Cancel-Safety.
-Intuitive definitions of these properties,
-attempting to capture the meaning of the standard definitions, follow.
+.IR Note :
+the text of this man page is based on the material taken from
+the "POSIX Safety Concepts" section of the GNU C Library manual.
+Further details on the topics described here can be found in that
+manual.
+.PP
+Various function manual pages include a section ATTRIBUTES
+that describes the safety of calling the function in various contexts.
+This section annotates functions with the following safety markings:
.TP
.I MT-Safe
.I MT-Safe
Thread-Safe functions are safe to call in the presence
of other threads.
MT, in MT-Safe, stands for Multi Thread.
-
+.IP
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
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.
-
+.IP
Whole-program optimizations that could inline functions across library
interfaces may expose unsafe reordering, and so performing inlining
across the GNU C Library interface is not recommended.
.\" 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
.\" .IR errno ,
.\" or modify the floating-point environment,
.\" 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
.\" .BR pthread_cancel (3),
.\" .BR pthread_setcancelstate (3),
.\" but does document which functions are presently AC-Safe.
.\" This documentation is provided for use
.\" by the GNU C Library developers.
-
+.\"
.\" Just like signal handlers, cancellation cleanup routines must configure
.\" the floating point environment they require.
.\" The routines cannot assume a floating point environment,
.\" 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.
.\" .TP
.\" .I not
.\" be counted on in future releases of
.\" the GNU C Library.
-.\"
+.\"
.\" 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
.\" 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,
.\" 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.
.\" .\" 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
.\" .I lock
.\" as an AC-Unsafe feature may, if canceled asynchronously,
.\" 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
.\" .I corrupt
.\" as an AC-Unsafe feature may leave
.\" data structures in a corrupt, partially updated state.
.\" Subsequent uses of the data structure may misbehave.
-.\"
+.\"
.\" .\" A special case, probably not worth documenting separately, involves
.\" .\" reallocing, or even freeing pointers. Any case involving free could
.\" .\" be easily turned into an ac-safe leak by resetting the pointer before
.\" Functions marked with
.\" .I heap
.\" may call heap memory management functions from the
-.\" .BR malloc (3)/ free (3)
+.\" .BR malloc (3)/ free (3)
.\" family of functions and are only as safe as those functions.
.\" This note is thus equivalent to:
-.\"
-.\" | AS-Unsafe lock | AC-Unsafe lock fd mem |
+.\"
+.\" | AS-Unsafe lock | AC-Unsafe lock fd mem |
.\" .\" @sampsafety{@asunsafe{@asulock{}}@acunsafe{@aculock{} @acsfd{} @acsmem{}}}
.\" .\"
.\" .\" Check for cases that should have used plugin instead of or in
.\" 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-Unsafe and AC-Unsafe,
.\" but other issues may arise.
.\" At present this is a placeholder for all
.\" potential safety issues raised by
.\" .BR dlopen (3).
-.\"
+.\"
.\" .\" dlopen runs init and fini sections of the module; does this mean
.\" .\" dlopen always implies plugin?
.\" .TP
.\" MT-Safe, AS-Unsafe and AC-Unsafe.
.\" Examples of such plugins are stack unwinding libraries,
.\" name service switch (NSS) and character set conversion (iconv) back-ends.
-.\"
+.\"
.\" Although the plugins mentioned as examples are all brought in by means
.\" of dlopen, the
.\" .I plugin
.\" family and will be only as safe as those
.\" functions.
.\" This note is thus equivalent to:
-.\"
-.\" | MT-Safe env | AS-Unsafe corrupt heap dlopen | AC-Unsafe corrupt |
-.\"
+.\"
+.\" | MT-Safe env | AS-Unsafe corrupt heap dlopen | AC-Unsafe corrupt |
+.\"
.\" .\" @sampsafety{@mtsafe{@mtsenv{}}@asunsafe{@asucorrupt{} @ascuheap{} @ascudlopen{}}@acunsafe{@acucorrupt{}}}
.\" .TP
.\" .I timer
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
+and each of their definitions indicates
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
.I init
as an MT-Unsafe feature perform
MT-Unsafe initialization when they are first called.
-
+.IP
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
.\" .I init
.\" as an AS-Unsafe or AC-Unsafe feature use the GNU C Library internal
.\" .I 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
.\" .I 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
.\" .I init
.\" as an AS-Safety or AC-Unsafe feature should ensure
.\" so that the AS-Safety and AC-Safety issues related with
.\" .I libc_once
.\" do not arise.
-.\"
+.\"
.\" .\" We may have to extend the annotations to cover conditions in which
.\" .\" initialization may or may not occur, since an initial call in a safe
.\" .\" context is no use if the initialization doesn't take place at that
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
.\" 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.
.\" 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.,
.\" .I 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.
-.\"
+.\"
.\" .\" 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
.\" 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.
Unlike
.IR race ,
which causes both readers and
-writers of internal objects to be regarded as MT-Unsafe and AS-Unsafe,
+writers of internal objects to be regarded as MT-Unsafe, \" and AS-Unsafe,
this mark is applied to writers only.
-Writers remain equally MT-Unsafe and AS-Unsafe to call,
+Writers remain \" equally
+MT-Unsafe \" 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),
+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.
-
+.IP
The identifier that follows the
.I 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-recursive
-.I rwlock
+read-write lock
associated with the identifier, and guard
.I all
calls to functions marked with
.\" 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.
-.\"
+.\"
.\" .\" But what if, instead of marking modifiers with const:id and readers
.\" .\" with just id, we marked writers with race:id and readers with ro:id?
.\" .\" Instead of having to define each instance of 'id', we'd have a
may temporarily install a signal handler for internal purposes,
which may interfere with other uses of the signal,
identified after a colon.
-
+.IP
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.
-
+.\"
+.\" 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.
+.\"
.\" .\" fixme: at least deferred cancellation should get it right, and would
.\" .\" obviate the restoring bit below, and the qualifier above.
-.\"
-Besides the measures recommended to work around the
-MT-Safety and AS-Safety problem,
-in order to avert the cancellation problem,
-disabling asynchronous cancellation
-.I and
-installing a cleanup handler to restore the signal to the desired state
-and to release the mutex are recommended.
+.\"
+.\" Besides the measures recommended to work around the
+.\" MT-Safety and AS-Safety problem,
+.\" in order to avert the cancellation problem,
+.\" disabling asynchronous cancellation
+.\" .I and
+.\" installing a cleanup handler to restore the signal to the desired state
+.\" and to release the mutex are recommended.
.TP
.I term
Functions marked with
Thus, functions marked with
.I 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.
-
+.\" 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.
+.IP
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,
The caller may use a single mutex for simplicity,
or use one mutex per terminal,
even if referenced by different file descriptors.
-
-Functions marked with
-.I 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 canceled.
-
-.\" fixme: at least deferred cancellation should get it right, and would
-.\" obviate the restoring bit below, and the qualifier above.
-
-Besides the measures recommended to work around the
-MT-Safety and AS-Safety problem,
-in order to avert the cancellation problem,
-disabling asynchronous cancellation
-.I and
-installing a cleanup handler to
-restore the terminal settings to the original state and to release the
-mutex are recommended.
+.\"
+.\" Functions marked with
+.\" .I 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 canceled.
+.\"
+.\" .\" fixme: at least deferred cancellation should get it right, and would
+.\" .\" obviate the restoring bit below, and the qualifier above.
+.\"
+.\" Besides the measures recommended to work around the
+.\" MT-Safety and AS-Safety problem,
+.\" in order to avert the cancellation problem,
+.\" disabling asynchronous cancellation
+.\" .I and
+.\" installing a cleanup handler to
+.\" restore the terminal settings to the original state and to release the
+.\" mutex are recommended.
.\"
.\"
.SS Other safety remarks
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-Unsafe or AS-Unsafe, however,
+.IP
+We do not mark these functions as MT-Unsafe, \" or AS-Unsafe,
+however,
because functions that modify the locale object are marked with
.I const:locale
and regarded as unsafe.
and so the locale can be considered effectively constant
in these contexts,
which makes the former safe.
-
.\" Should the locking strategy suggested under @code{const} be used,
.\" failure to guard locale uses is not as fatal as data races in
.\" general: unguarded uses will @emph{not} follow dangling pointers or
.BR getenv (3)
or similar, without any guards to ensure
safety in the presence of concurrent modifications.
-
-We do not mark these functions as MT-Unsafe or AS-Unsafe, however,
+.IP
+We do not mark these functions as MT-Unsafe, \" or AS-Unsafe,
+however,
because functions that modify the environment are all marked with
.I const:env
and regarded as unsafe.
.I _sigintr
internal data structure without any guards to ensure
safety in the presence of concurrent modifications.
-
-We do not mark these functions as MT-Unsafe or AS-Unsafe, however,
-because functions that modify the this data structure are all marked with
+.IP
+We do not mark these functions as MT-Unsafe, \" or AS-Unsafe,
+however,
+because functions that modify this data structure are all marked with
.I const:sigintr
and regarded as unsafe.
Being unsafe,
and so the data structure can be considered
effectively constant in these contexts,
which makes the former safe.
-.TP
-.I fd
-Functions annotated with
-.I 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.
-.TP
-.I mem
-Functions annotated with
-.I 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.
+.\" .TP
+.\" .I fd
+.\" Functions annotated with
+.\" .I 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.
+.\" .TP
+.\" .I mem
+.\" Functions annotated with
+.\" .I 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.
.TP
.I cwd
Functions marked with
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-Unsafe or
-AS-Unsafe, but when this behavior is optional (e.g.,
+.IP
+This is not enough of a reason to mark so-marked functions as MT-Unsafe,
+.\" or AS-Unsafe,
+but when this behavior is optional (e.g.,
.BR nftw (3)
with
.BR FTW_CHDIR ),
using full pathnames or file descriptor-relative (e.g.,
.BR openat (2))
system calls.
-.TP
-.I !posix
-This remark, as an MT-Safety, AS-Safety 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.
+.\" .TP
+.\" .I !posix
+.\" This remark, as an MT-Safety, AS-Safety 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.
.TP
.I :identifier
Annotations may sometimes be followed by identifiers,
and
.I corrupt
as well in the future.
-
+.IP
In most cases, the identifier will name a set of functions,
but it may name global objects or function arguments,
or identifiable properties or logical components associated with them,
.I :tcattr(fd)
to denote the terminal attributes of a file descriptor
.IR fd .
-
+.IP
The most common use for identifiers is to provide logical groups of
functions and arguments that need to be protected by the same
synchronization primitive in order to ensure safe operation in a given
.I /condition
Some safety annotations may be conditional,
in that they only apply if a boolean expression involving arguments,
-global variables or even the underlying kernel evaluates evaluates to true.
-Such conditions as
-.I /hurd
-or
-.I /!linux!bsd
-indicate the preceding marker only
-applies when the underlying kernel is the HURD,
-or when it is neither Linux nor a BSD kernel, respectively.
-.I !ps
+global variables or even the underlying kernel evaluates to true.
+.\" Such conditions as
+.\" .I /hurd
+.\" or
+.\" .I /!linux!bsd
+.\" indicate the preceding marker only
+.\" applies when the underlying kernel is the HURD,
+.\" or when it is neither Linux nor a BSD kernel, respectively.
+For example,
+.I /!ps
and
.I /one_per_line
indicate the preceding marker only applies when argument
is NULL, or global variable
.I one_per_line
is nonzero.
-
+.IP
When all marks that render a function unsafe are
adorned with such conditions,
and none of the named conditions hold,
then the function can be regarded as safe.
+.SH SEE ALSO
+.BR pthreads (7)
projects / thirdparty / man-pages.git / blobdiff