Fuzz

14 files changed, 82 insertions, 70 deletions

diff --git a/TAO/examples/AMH/Sink_Server/README b/TAO/examples/AMH/Sink_Server/README
index a7d020ef6f1..9313466070d 100644
--- a/TAO/examples/AMH/Sink_Server/README
+++ b/TAO/examples/AMH/Sink_Server/README
@@ -1,3 +1,5 @@
+$Id$
+
 Files:
 ------
 AMH_Servant.h/cpp     : AMH Servant that implements the Test interface
@@ -21,7 +23,7 @@ Multi  Threaded Server: make mt_server
 Running the servers:
 --------------------
 Single threaded AMH Sink Server:
-st_server -ORBsvcconf st_server.conf -o <ior_output_file> -s <sleep_time (in microseconds)> 
+st_server -ORBsvcconf st_server.conf -o <ior_output_file> -s <sleep_time (in microseconds)>
 
 e.g.: st_server -o test.ior -s 20000
 to delay a reply to the client by 20 milliseconds.
@@ -40,7 +42,7 @@ necessary and there are no defaults
 How the server works:
 ---------------------
 - Each client request is 'timed' (with the sleep_time) and registered
-in the ORB's reactor.  
+in the ORB's reactor.
 
 - Upon expiration of the timer, the reactor fires the timer_handler
 and the AMH RH servant method is called to send the reply to the
diff --git a/TAO/examples/Advanced/README b/TAO/examples/Advanced/README
index 89a3212d3b7..dc61d9bfa52 100644
--- a/TAO/examples/Advanced/README
+++ b/TAO/examples/Advanced/README
@@ -10,7 +10,7 @@ We've also integrated the examples into the ACE+TAO Makefile scheme.
 Each directory contains a file CHANGES which describes all
 modifications, as well as a README file documenting its use.
 
-The original source distribution can be found at the Addison-Wesley 
+The original source distribution can be found at the Addison-Wesley
 homepage:
 
 http://cseng.aw.com/bookdetail.qry?ISBN=0-201-37927-9&ptype=0
diff --git a/TAO/examples/Advanced/ch_12/README b/TAO/examples/Advanced/ch_12/README
index d099fbc905c..c2741364efe 100644
--- a/TAO/examples/Advanced/ch_12/README
+++ b/TAO/examples/Advanced/ch_12/README
@@ -2,38 +2,38 @@ $Id$
 
 Chapter 12 example.
 ______________________________________________________________________________
-This example been taken from the book "Advanced CORBA Programming with C++" 
-by Michi Henning and Steve Vinoski. Copyright 1999. Addison-Wesley, Reading, 
-MA.  To make the examples work with TAO, some minor modifications to the 
+This example been taken from the book "Advanced CORBA Programming with C++"
+by Michi Henning and Steve Vinoski. Copyright 1999. Addison-Wesley, Reading,
+MA.  To make the examples work with TAO, some minor modifications to the
 source code have been made, with permission, by Mike Moran <mm4@cs.wustl.edu>.
 All of these changes are documented in the file CHANGES, in this directory.
 ______________________________________________________________________________
 
 
 Summary:
-    This example builds on the climate control system presented in chapters 8 
-    and 10.   The added use of customized POA policies including the use of a 
-    servant manager is discussed in chapter 11.  The example also incorporates 
-    a simulated ICP network within the server process with code from Appendix 
+    This example builds on the climate control system presented in chapters 8
+    and 10.   The added use of customized POA policies including the use of a
+    servant manager is discussed in chapter 11.  The example also incorporates
+    a simulated ICP network within the server process with code from Appendix
     A.  The simulated network loads it's devices from
- 
+
 Building:
-    This example must be built with native C++ exceptions, and with an ACE/TAO 
-    build with exceptions.  Make sure to use TAO_FLAG Ge=0 to ensure that the 
-    IDL generated code uses c++ exceptions rather than creating 
+    This example must be built with native C++ exceptions, and with an ACE/TAO
+    build with exceptions.  Make sure to use TAO_FLAG Ge=0 to ensure that the
+    IDL generated code uses c++ exceptions rather than creating
     CORBA_Environment variables.
 
-    With GNU make, simply type 
+    With GNU make, simply type
      % make exceptions=1
     to create the executable server and client
 
 server:
-    The server takes no parameters nor command line options and returns an 
+    The server takes no parameters nor command line options and returns an
     IOR to stdout.  The server then waits infinitely for clients requests.
 
 client:
-    The client takes an IOR from the command line, narrows this to a 
-    controller reference, makes several remote calls on this controller, and 
+    The client takes an IOR from the command line, narrows this to a
+    controller reference, makes several remote calls on this controller, and
     finally terminates.
 
 run_test.pl:
diff --git a/TAO/examples/Advanced/ch_3/README b/TAO/examples/Advanced/ch_3/README
index e74eeb9bdf1..9d87f6affd2 100644
--- a/TAO/examples/Advanced/ch_3/README
+++ b/TAO/examples/Advanced/ch_3/README
@@ -2,9 +2,9 @@ $Id$
 
 Chapter 3 example.
 ______________________________________________________________________________
-This example been taken from the book "Advanced CORBA Programming with C++" 
-by Michi Henning and Steve Vinoski. Copyright 1999. Addison-Wesley, Reading, 
-MA.  To make the examples work with TAO, some minor modifications to the 
+This example been taken from the book "Advanced CORBA Programming with C++"
+by Michi Henning and Steve Vinoski. Copyright 1999. Addison-Wesley, Reading,
+MA.  To make the examples work with TAO, some minor modifications to the
 source code have been made, with permission, by Mike Moran <mm4@cs.wustl.edu>.
 All of these changes are documented in the file CHANGES, in this directory.
 ______________________________________________________________________________
@@ -12,28 +12,28 @@ ______________________________________________________________________________
 
 Summary:
     This is the simple time server given in chapter 3 of the book.
-    There is a server process which holds a servant object which can return 
-    the current Greenwich time, and a client process which can acess this 
+    There is a server process which holds a servant object which can return
+    the current Greenwich time, and a client process which can acess this
     object.
 
 Building:
-    This example must be built with native C++ exceptions, and with an ACE/TAO 
+    This example must be built with native C++ exceptions, and with an ACE/TAO
     build with exceptions.  Make sure to use TAO_FLAG Ge=0 to ensure
-    that CORBA::Environment variables are not created in the IDL generated 
+    that CORBA::Environment variables are not created in the IDL generated
     stubs and skeletons.
 
-    With GNU make, simply type 
-                            
+    With GNU make, simply type
+
     % make exceptions=1
 
     to create the executable server and client
 
 server:
-    The server takes no parameters nor command line options and returns an 
+    The server takes no parameters nor command line options and returns an
     IOR to stdout.  The server then waits infinitely for clients requests.
 
 client:
-    The client takes an IOR from the command line, prints out the current 
+    The client takes an IOR from the command line, prints out the current
     time, and terminates.
 
 run_test.pl:
diff --git a/TAO/examples/CSD_Strategy/ThreadPool5/README b/TAO/examples/CSD_Strategy/ThreadPool5/README
index 29b72f8a861..234c4fab331 100644
--- a/TAO/examples/CSD_Strategy/ThreadPool5/README
+++ b/TAO/examples/CSD_Strategy/ThreadPool5/README
@@ -1,8 +1,8 @@
-# $Id$
+$Id$
 
 Description:
 
-This test is a combination of other tests and has also added some 
+This test is a combination of other tests and has also added some
 other test cases such as cancel_servant. It uses the command
 line options for the number of orb threads, number of servants,
 collocated test options, etc.
@@ -18,15 +18,15 @@ $ ./run_test.pl
 
 $ ./run_test.pl collocated
 
-        This runs the collocated test. 
+        This runs the collocated test.
 
-        The server application creates one servant, runs one orb 
-        thread, runs two custom dispatching threads and one client 
+        The server application creates one servant, runs one orb
+        thread, runs two custom dispatching threads and one client
         thread to invoke the operations.
 
-        Running two custom dispatching threads instead of one is 
+        Running two custom dispatching threads instead of one is
         required to avoid deadlock.
-  
+
 $ ./run_test.pl multiple_servants
 
         This test is similar to the "ThreadPool2" test.
@@ -41,7 +41,7 @@ $ ./run_test.pl cancel_servant
         cancelled when a servant is deactivated.
 
         The client invokes multiple two-way operations and catches the
-        OBJECT_NOT_EXIST or NO_IMPLEMENTATION exception after the servant 
+        OBJECT_NOT_EXIST or NO_IMPLEMENTATION exception after the servant
         is deactivated - this is what it is supposed to do - the exceptions
         are expected.
 
diff --git a/TAO/examples/Content_Server/AMI_Iterator/README b/TAO/examples/Content_Server/AMI_Iterator/README
index eaca92782ab..c20e3ff5b64 100644
--- a/TAO/examples/Content_Server/AMI_Iterator/README
+++ b/TAO/examples/Content_Server/AMI_Iterator/README
@@ -1,3 +1,5 @@
+$Id$
+
 This program illustrates how to implement a simple client and server
 using CORBA, IIOP, and asynchronous method invocations (AMI).  Client
 applications can use this service to download and display files from a
@@ -15,9 +17,9 @@ is as follows:
 
         * The CORBA Naming Service is used to bind and resolve object
           references, rather than using a file.
-    
+
 The client program performs the following activities:
-          
+
         1. From the command-line, it reads the name of the pathname
            you want to download.  It then initializes the client-side
            ORB and uses resolve_initial_references() to obtain a
@@ -29,7 +31,7 @@ The client program performs the following activities:
            interface, the get_iterator() operation is called via the
            object reference to obtain the Chunk_Iterator, which is
            used to download the file.
-          
+
         2. The client invokes the sendc_next_chunk() method on the
            iterator, passing in the offset and the object reference to
            the client's reply handler.  Only one pending call at a
@@ -37,14 +39,14 @@ The client program performs the following activities:
            some type of offset parameter to the next_chunk() callback
            to perform reassembly if chunks for the same file arrived
            out of order.
-          
+
         3. When next_chunk() returns a chunk of the file, the contents
            are written into a temporary file created in your a cache
            (e.g., /tmp/yourloginname) on the local host.  Then, an
            external viewer is spawned to display the file.  The type
            of viewer to spawn is determined by examining the the
            content_type_ metadata returned by the server.
-       
+
 The example can be run as follows:
 
 	1. Start the Name Service:
diff --git a/TAO/examples/Content_Server/AMI_Observer/README b/TAO/examples/Content_Server/AMI_Observer/README
index f9e4de33b5d..10d91d298f7 100644
--- a/TAO/examples/Content_Server/AMI_Observer/README
+++ b/TAO/examples/Content_Server/AMI_Observer/README
@@ -1,3 +1,5 @@
+$Id$
+
 This program illustrates how to implement a simple client and server
 using CORBA, IIOP, and asynchronous method invocations (AMI).  Client
 applications can use this service to download and display files from a
@@ -8,7 +10,7 @@ is as follows:
            the Observer pattern.  The server will ``push'' chunks of
            data to the client.  Thus, the client will play the role of
            a ``server,'' as well.
-           
+
         * Operations in the IDL interface will use exceptions to propagate
           problems back to clients.
 
@@ -75,7 +77,7 @@ the client receives all chunks of data in the proper order.
 
 
 The client program performs the following activities:
-          
+
         1. From the command-line, it reads the name of the pathname
            you want to download.  It then initializes the client-side
            ORB and uses resolve_initial_references() to obtain a
@@ -88,10 +90,10 @@ The client program performs the following activities:
            called via the object reference to pass asynchronously pass
            the Callback interface from the client to the server, which
            then uses AMI to push chunks of the file to the client.
-          
+
         2. The server calls the sendc_next_chunk() method on the
-           callback, passing in the offset and the next chunk.  
-          
+           callback, passing in the offset and the next chunk.
+
         3. When the client receives the next_chunk() callback that
            contains a chunk of the file, the contents are written into
            a temporary file created in your a cache (e.g.,
@@ -99,8 +101,8 @@ The client program performs the following activities:
            viewer is spawned to display the file.  The type of viewer
            to spawn is determined by examining the the content_type_
            metadata returned by the server.
-	
-       
+
+
 The example can be run as follows:
 
 	1. Start the Name Service:
diff --git a/TAO/examples/Content_Server/SMI_Iterator/README b/TAO/examples/Content_Server/SMI_Iterator/README
index f89a45e7747..d6fea3f7e52 100644
--- a/TAO/examples/Content_Server/SMI_Iterator/README
+++ b/TAO/examples/Content_Server/SMI_Iterator/README
@@ -1,3 +1,5 @@
+$Id$
+
 This program illustrates how to implement a simple client and server
 using CORBA, IIOP, and synchronous method invocations (SMI).  Client
 applications can use this service to download and display files from a
@@ -14,9 +16,9 @@ is as follows:
 
         * The CORBA Naming Service is used to bind and resolve object
           references, rather than using a file.
-    
+
 The client program performs the following activities:
-          
+
         1. From the command-line, it reads the name of the pathname
            you want to download.  It then initializes the client-side
            ORB and uses resolve_initial_references() to obtain a
@@ -28,7 +30,7 @@ The client program performs the following activities:
            interface, the get_iterator() operation is called via the
            object reference to obtain the Chunk_Iterator, which is
            used to download the file.
-          
+
         2. When next_chunk() returns a chunk of the file, the contents
            are written into a temporary file created in your a cache
            (e.g., /tmp/yourloginname) on the local host.  Then, an
diff --git a/TAO/examples/Logging/README b/TAO/examples/Logging/README
index 685d2d9d7ae..8185016d254 100644
--- a/TAO/examples/Logging/README
+++ b/TAO/examples/Logging/README
@@ -1,4 +1,4 @@
-$ID$
+$Id$
 
 This example implements and tests runs a simple logging service using
 TAO.  You can either run the client and server as seperate processes
@@ -20,10 +20,10 @@ in the run_test.pl script.
 The client program will generate 4 logging messages which will be
 logged to the screen. The first message will be in the "verbose_lite"
 format. The rest will be fully verbose messages. Successful output is:
-LM_DEBUG@::log() test (1) 
-Mar  8 16:31:06.000 1999@128.252.165.142@822@LM_EMERGENCY@::log() test (2) 
-Mar  8 16:31:06.000 1999@128.252.165.142@822@LM_INFO@::logv() test (3) 
-Mar  8 16:31:06.000 1999@128.252.165.142@822@LM_EMERGENCY@::log2() test (4) 
+LM_DEBUG@::log() test (1)
+Mar  8 16:31:06.000 1999@128.252.165.142@822@LM_EMERGENCY@::log() test (2)
+Mar  8 16:31:06.000 1999@128.252.165.142@822@LM_INFO@::logv() test (3)
+Mar  8 16:31:06.000 1999@128.252.165.142@822@LM_EMERGENCY@::log2() test (4)
 
 server: ------
 
diff --git a/TAO/examples/Persistent_Grid/README b/TAO/examples/Persistent_Grid/README
index ea5b1771acf..20daff85a28 100644
--- a/TAO/examples/Persistent_Grid/README
+++ b/TAO/examples/Persistent_Grid/README
@@ -21,7 +21,7 @@ Options:
 -o    Outputs the ior to the file
       The ior is the reference using which the client can interact with
       the target server object.
--m    Name of the memory pool. 
+-m    Name of the memory pool.
 
 
 When the server is started, you should see as the first line of output
@@ -50,7 +50,7 @@ Options:
 -w    Width of the grid
 -h    Height of the grid
 -v    Value that needs to be the starting point for storage. The value
-      that is stored will be this value + location id. 
+      that is stored will be this value + location id.
 
 persistent_client:
 -----------------
diff --git a/TAO/examples/PluggableUDP/DIOP/README b/TAO/examples/PluggableUDP/DIOP/README
index b1522ddd5c3..4ff672dab49 100644
--- a/TAO/examples/PluggableUDP/DIOP/README
+++ b/TAO/examples/PluggableUDP/DIOP/README
@@ -1,3 +1,5 @@
+$Id$
+
 DIOP - UDP Based Pluggable Protocol
 ===================================
 
@@ -30,7 +32,7 @@ Notes on the DIOP implementation:
   TAO Connector.  It installs a connection handler on the first
   invocation on a remote CORBA object.
 
-DIOP Installation 
+DIOP Installation
 
 - The application using DIOP should have a svc.conf file with the
   following entry:
diff --git a/TAO/examples/PluggableUDP/tests/Performance/README b/TAO/examples/PluggableUDP/tests/Performance/README
index 9f3e318ce64..923c74e97a7 100644
--- a/TAO/examples/PluggableUDP/tests/Performance/README
+++ b/TAO/examples/PluggableUDP/tests/Performance/README
@@ -1,17 +1,18 @@
+$Id$
 
 Performance tests for the performance of the DIOP
 implementation using oneways in a roundtrip manor.
 This means that the client sends a request to the server,
-which in turn sends a request to the client. 
+which in turn sends a request to the client.
 
-1000 oneway requests containing a sequence of 256 chars are 
+1000 oneway requests containing a sequence of 256 chars are
 performed and the average time per call is measured.
 
 To execute the test either
 
 - use run_test.pl, or
 
-- start 
+- start
 
    server -o ior -ORBendpoint diop://:12345
 
diff --git a/TAO/examples/PluggableUDP/tests/SimplePerformance/README b/TAO/examples/PluggableUDP/tests/SimplePerformance/README
index 578bdc972b9..07e027ebd6f 100644
--- a/TAO/examples/PluggableUDP/tests/SimplePerformance/README
+++ b/TAO/examples/PluggableUDP/tests/SimplePerformance/README
@@ -1,8 +1,9 @@
+$Id$
 
 Performance tests for the performance of the DIOP
-implementation using oneways. 
+implementation using oneways.
 
-1000 oneway requests containing a sequence of 256 chars are 
+1000 oneway requests containing a sequence of 256 chars are
 performed and the average time per call is measured.
 
 To execute the test either
diff --git a/TAO/examples/Simple/README b/TAO/examples/Simple/README
index d753ece9ea5..fab2e136df6 100644
--- a/TAO/examples/Simple/README
+++ b/TAO/examples/Simple/README
@@ -7,22 +7,22 @@ features.  The individual directories contain READMEs on how to run
 the following tests:
 
         . bank
-        
+
           This directory implements the canonical VisiBroker
           test.
 
         . chat
-        
+
           This directory implements an ORBacus test.
 
         . echo
-        
+
           This directory implements the canonical omniORB test.
 
         . grid
-        
+
           This directory implements the canonical Orbix test.
 
         . time
-          
+
           This directory implements a simple time/date test.