Removed whitespace at end-of-line; no content changes. I simply did

cd src/share; find man[1-9] -type f|xargs perl -pi -e 's/[ \t]+$//'

BTW, what editors are the culprits? I'm using vim and it shows
me whitespace at EOL in troff files with a thick blue block...

Reviewed by:	Silence from cvs diff -b
MFC after:	7 days

1 files changed, 20 insertions, 20 deletions

diff --git a/share/man/man4/man4.i386/svr4.4 b/share/man/man4/man4.i386/svr4.4
index a9d9d85..08a04fb 100644
--- a/share/man/man4/man4.i386/svr4.4
+++ b/share/man/man4/man4.i386/svr4.4
@@ -74,25 +74,25 @@ implementation is provided.
 .Sh LIMITATIONS
 Because the provided ABI has been developed in ignorance of actual SVR4
 source code, there are bound to be unforseen interactions between SVR4
-client applications and the emulated ABI which cause applications to 
-malfunction.  
+client applications and the emulated ABI which cause applications to
+malfunction.
 .Pp
 Additionally, some SVR4 operating systems do not adhere to the SVR4
 ELF standard.
 In particular, Solaris does not set the ELF interpreter field in the
-ELF header to a value which would allow the kernel to correctly 
+ELF header to a value which would allow the kernel to correctly
 identify a client executable as an SVR4 application.
-Thus, in certain instances it is necessary to use the 
+Thus, in certain instances it is necessary to use the
 .Xr brandelf 1
 utility to explicitly brand the executable, or to set the
 kern.fallback_elf_brand
 .Xr sysctl 8
-variable to define a "default" ABI for unbranded executables. 
+variable to define a "default" ABI for unbranded executables.
 Value ELFOSABI_SOLARIS represents Solaris; ELFOSABI_SYSV represents other
 SysVR4 operating systems.
-See 
+See
 .Pa /usr/include/sys/elf_common.h
-for ELFOSABI branding definitions, and 
+for ELFOSABI branding definitions, and
 .Xr brandelf 1
 for information on branding executables.
 .Pp
@@ -131,22 +131,22 @@ regardless of whether the
 module is statically linked into the kernel
 or loaded as a module.
 .Pp
-STREAMS emulation is limited but (largely) functional. 
+STREAMS emulation is limited but (largely) functional.
 Assuming the
 .Xr streams 4
-module is loaded, a STREAMS handle can be obtained by opening one of the 
+module is loaded, a STREAMS handle can be obtained by opening one of the
 relevent files in
 .Pa /dev
-or 
+or
 .Pa /compat/svr4/dev .
-Internally, the 
+Internally, the
 .Xr streams 4
 driver produces a socket descriptor and "tags" it with additional STREAMS
-state information before returning it to the client application. 
+state information before returning it to the client application.
 The
 .Nm
-environment uses the additional state information to recognize and 
-manipulate emulated STREAMS handles when STREAMS-specific 
+environment uses the additional state information to recognize and
+manipulate emulated STREAMS handles when STREAMS-specific
 .Xr ioctl 2
 calls are executed.
 .Pp
@@ -160,7 +160,7 @@ Emulated connectionless STREAMS fail to receive data from the network in
 some circumstances (but succeed in others -- probably due to particular
 ways of initializing them which the
 .Xr streams 4
-module is mishandling, and interaction between STREAMS and 
+module is mishandling, and interaction between STREAMS and
 .Xr poll 2 ) .
 Connection-oriented STREAMS appear to be functional.
 .Pp
@@ -168,7 +168,7 @@ Ironically, this SVR4 emulator does not (yet) support SVR4 semaphores or
 shared memory.
 .Pp
 .Xr ports 7
-to automatically create the 
+to automatically create the
 .Pa /compat/svr4
 environment do not exist.
 .Xr tar 1
@@ -178,9 +178,9 @@ archives containing pre-populated trees can be obtained from
 Extensive testing has only really been carried out with Solaris 2.x binaries,
 with anecdotal reports of limited success coming from testers with
 early-revision SCO media.  In theory, the basic SVR4 ABI should be constant
-across the set of vendors who produce SVR4 operating systems, but in 
-practice that's probably not the case.  If necessary, future work can 
-either implement additional 
+across the set of vendors who produce SVR4 operating systems, but in
+practice that's probably not the case.  If necessary, future work can
+either implement additional
 .Xr kld 4
 modules which produce functionality which contains OS-dependent
 departures from the behaviour which has been implemented in this
@@ -194,7 +194,7 @@ client applications.
 .It Pa /compat/svr4
 minimal SVR4 run-time environment
 .It Pa /sys/compat/svr4/syscalls.master
-mappings between SVR4 syscalls and 
+mappings between SVR4 syscalls and
 .Nm
 module entrypoints.
 .El