LDP
/
man-pages
mirror of https://github.com/mkerrisk/man-pages
0
1
Fork 0
Code Releases Activity

attributes.7: Comment out 'Preliminary' description 

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2014-10-18 12:10:41 +02:00
parent 2a089d935c
commit dfe3ffe830
1 changed files with 47 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

94
man7/attributes.7
View File

@ -118,53 +118,53 @@ functions are not safe to call in a multithreaded programs.
.\"
.\" Functions not explicitly documented as safe in a safety context should
.\" be regarded as Unsafe.
.TP
.I Preliminary
.I Preliminary
safety properties are documented, indicating these
properties may
.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
requirements.
The latter are most likely bugs; the former, when marked
as
.IR 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
.I Preliminary
keyword from safety notes.
As long as the keyword remains, however,
they are not to be regarded as a promise of future behavior.
.\" .TP
.\" .I Preliminary
.\" .I Preliminary
.\" safety properties are documented, indicating these
.\" properties may
.\" .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
.\" requirements.
.\" The latter are most likely bugs; the former, when marked
.\" as
.\" .IR 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
.\" .I Preliminary
.\" keyword from safety notes.
.\" As long as the keyword remains, however,
.\" they are not to be regarded as a promise of future behavior.
.PP
Other keywords that appear in safety notes are defined in subsequent sections.
.\"