1 files changed, 47 insertions, 47 deletions
diff --git a/man7/attributes.7 b/man7/attributes.7
index 28e6311ffc..21e5671213 100644
--- a/man7/attributes.7
+++ b/man7/attributes.7
@@ -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.
 .\"