Removed trailing white space at end of lines

2 files changed, 7 insertions, 7 deletions

diff --git a/man3/pthread_rwlockattr_setkind_np.3 b/man3/pthread_rwlockattr_setkind_np.3
index e0d1dd55c..bf7f7c680 100644
--- a/man3/pthread_rwlockattr_setkind_np.3
+++ b/man3/pthread_rwlockattr_setkind_np.3
@@ -24,7 +24,7 @@
 .\"
 .TH PTHREAD_RWLOCKATTR_SETKIND_NP 3 2014-10-15 "Linux Programmer's Manual"
 .SH NAME
-pthread_rwlockattr_setkind_np, pthread_rwlockattr_getkind_np \- set/get 
+pthread_rwlockattr_setkind_np, pthread_rwlockattr_getkind_np \- set/get
 the read-write lock kind of the thread read-write lock attribute object
 .SH SYNOPSIS
 .nf
@@ -65,7 +65,7 @@ may be set to one of the following:
 .TP
 .B PTHREAD_RWLOCK_PREFER_READER_NP
 This is the default.
-A thread may hold multiple read locks; that is, read locks are recursive. 
+A thread may hold multiple read locks; that is, read locks are recursive.
 According to The Single Unix Specification, the behavior is unspecified when a
 reader tries to place a lock, and there is no write lock but writers are
 waiting.
@@ -82,7 +82,7 @@ This is intended as the write lock analog of
 But see BUGS.
 .TP
 .B PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP
-Setting the lock kind to this 
+Setting the lock kind to this
 avoids writer starvation as long as any read locking is not done in a
 recursive fashion.
 .PP
@@ -111,7 +111,7 @@ Setting the value read-write lock kind to
 .BR  PTHREAD_RWLOCK_PREFER_WRITER_NP
 results in the same behavior as setting the value to
 .BR PTHREAD_RWLOCK_PREFER_READER_NP .
-As long as a reader thread holds the lock, the thread holding a 
+As long as a reader thread holds the lock, the thread holding a
 write lock will be starved.
 Setting the lock kind to
 .BR PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP
diff --git a/man7/unix.7 b/man7/unix.7
index 875f69eb8..1ab70d5f2 100644
--- a/man7/unix.7
+++ b/man7/unix.7
@@ -79,7 +79,7 @@ Various systems calls (for example,
 and
 .BR sendto (2))
 take a
-.I sockaddr_un 
+.I sockaddr_un
 argument as input.
 Some other system calls (for example,
 .BR getsockname (2),
@@ -178,7 +178,7 @@ structure should have a value of at least:
     offsetof(struct sockaddr_un, sun_path)+strlen(addr.sun_path)+1
 .fi
 .IP
-or, more simply, 
+or, more simply,
 .I addrlen
 can be specified as
 .IR "sizeof(struct sockaddr_un)" .
@@ -554,7 +554,7 @@ and when the socket address is retrieved on these implementations,
 there is no null terminator in
 .IR sun_path .
 
-Applications that retrieve socket addresses can (portably) code 
+Applications that retrieve socket addresses can (portably) code
 to handle the possibility that there is no null terminator in
 .IR sun_path
 by respecting the fact that the number of valid bytes in the pathname is: