Removed trailing white space at end of lines

man3/canonicalize_file_name.3

@@ -71,7 +71,7 @@ to indicate the error.
 See
 .BR realpath (3).
 .SH ATTRIBUTES
-For an explanation of the terms used in this section, see 
+For an explanation of the terms used in this section, see
 .BR attributes (7).
 .TS
 allbox;

man3/getlogin.3

@@ -169,8 +169,8 @@ In the above table,
 in
 .I race:utent
 signifies that if any of the functions
-.BR setutent (3), 
-.BR getutent (3), 
+.BR setutent (3),
+.BR getutent (3),
 or
 .BR endutent (3)
 are used in parallel in different threads of a program,

man3/mtrace.3

@@ -91,7 +91,7 @@ T{
 .\" mtrace: MT-Unsafe env race:mtrace const:malloc_hooks init
 .\" muntrace: MT-Unsafe race:mtrace const:malloc_hooks locale
 .\" But there is something wrong in glibc manual, for example:
-.\" glibc manual says muntrace should have marking locale because it calls 
+.\" glibc manual says muntrace should have marking locale because it calls
 .\" fprintf(), but muntrace does not execute area which cause locale problem.
 T}	Thread safety	MT-Unsafe
 .TE

man3/tgamma.3

@@ -158,7 +158,7 @@ is not set for this case.
 .SH VERSIONS
 These functions first appeared in glibc in version 2.1.
 .SH ATTRIBUTES
-For an explanation of the terms used in this section, see 
+For an explanation of the terms used in this section, see
 .BR attributes (7).
 .TS
 allbox;

man7/attributes.7

@@ -30,7 +30,7 @@ attributes \- POSIX safety concepts
 .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 
+Further details on the topics described here can be found in that
 manual.
 
 Various function manual pages include a section ATTRIBUTES
@@ -66,7 +66,7 @@ safe for inlining.
 .\" 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,
@@ -87,7 +87,7 @@ safe for inlining.
 .\" 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),
@@ -114,7 +114,7 @@ functions are not safe to call in a multithreaded programs.
 .\" 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
@@ -125,12 +125,12 @@ functions are not safe to call in a multithreaded programs.
 .\" .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
@@ -141,7 +141,7 @@ functions are not safe to call in a multithreaded programs.
 .\" 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,
@@ -151,11 +151,11 @@ functions are not safe to call in a multithreaded programs.
 .\" 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.
@@ -185,7 +185,7 @@ Other keywords that appear in safety notes are defined in subsequent sections.
 .\" .\" 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,
@@ -207,13 +207,13 @@ Other keywords that appear in safety notes are defined in subsequent sections.
 .\" 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
@@ -233,11 +233,11 @@ Other keywords that appear in safety notes are defined in subsequent sections.
 .\" 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
@@ -253,13 +253,13 @@ Other keywords that appear in safety notes are defined in subsequent sections.
 .\" 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
@@ -272,7 +272,7 @@ Other keywords that appear in safety notes are defined in subsequent sections.
 .\" 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
@@ -300,9 +300,9 @@ Other keywords that appear in safety notes are defined in subsequent sections.
 .\" 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
@@ -351,17 +351,17 @@ the function can then be safely called after other threads are started.
 .\" 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
@@ -370,7 +370,7 @@ the function can then be safely called after other threads are started.
 .\" 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
@@ -407,7 +407,7 @@ in others, they are not even exposed to users.
 .\" 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.
@@ -422,7 +422,7 @@ in others, they are not even exposed to users.
 .\" 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.,
@@ -448,16 +448,16 @@ in others, they are not even exposed to users.
 .\" .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
@@ -480,7 +480,7 @@ in others, they are not even exposed to users.
 .\" 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.
@@ -535,7 +535,7 @@ 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.
-.\" 
+.\"
 .\" .\" 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
@@ -567,10 +567,10 @@ 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.
-.\" 
+.\"
 .\" .\" 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,
@@ -615,10 +615,10 @@ even if referenced by different file descriptors.
 .\" 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,
@@ -736,7 +736,7 @@ which makes the former safe.
 .\" 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
@@ -754,7 +754,7 @@ which makes the former safe.
 .\" 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,
@@ -763,7 +763,7 @@ which makes the former safe.
 .\" 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
@@ -777,14 +777,14 @@ which makes the former safe.
 .\" .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
@@ -817,7 +817,7 @@ system calls.
 .\" 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.