Correct spelling mistakes

Several spelling errors not corrected before last merge.

Signed-off-by: E. Scott Daniels <daniels@research.att.com>
Change-Id: I181a8d34f51005ee3f1fe64b4d685c189f4673de

diff --git a/BUILD b/BUILD
index 17ed743..bf4121a 100644 (file)
--- a/BUILD
+++ b/BUILD
@@ -54,7 +54,7 @@ the configuration:
   -DMAN_PREFIX=<path>  Supply a path where man pages are installed (default: /usr/share/man)
   -DPACK_EXTERNALS=1   Include external libraries used to build in the run-time package
   -DPRESERVE_PTYPE=1   Do not change the processor type when naming deb packages
-  -DSKIP_EXTERNALS=1   Do not use Nano/NNG submodules when building; uee installed packages
+  -DSKIP_EXTERNALS=1   Do not use Nano/NNG submodules when building; use installed packages
 
 
 Packages
@@ -70,7 +70,7 @@ Resulting package names are illustrated in the CI section below.
 Continuous Integration Build
 Use the Dockerfile in the ci/ subdirectory. This installs all
 the required tools, then builds RMR and executes the unit and
-programm tests. If tests pass, then  an image is created in the
+program tests. If tests pass, then  an image is created in the
 local registry with both run-time and development packages.
 
 To support the distribution of package(s) created during the
@@ -121,7 +121,7 @@ libraries (.e.g -L) on the command line, or via environment
 variables (e.g.. C_INCLUDE_PATH, LD_LIBRARY_PATH, LIBRARY_PATH).
 It may also be necessary to have the library directory defined
 in the environment at run time.  It is difficult to know what
-each system needs, but the following linker ooptions  work when
+each system needs, but the following linker options  work when
 libraries are installed in the system spots:
 
        -lrmr_nng -lnng -lpthread
@@ -134,7 +134,7 @@ a different spot (e.g. in $HOME/usr):
 
 Libraries
 RMR supports only NNG as the underlying transport. Nanomsg
-support was dropped in starting with version 1.0.45 as Nanomsg
+support was dropped starting with version 1.0.45 as Nanomsg
 has reached end of life. The package generation and install
 will produce a single RMR library:  librmr_nng.  RMR is designed
 to support different underlying transport mechanisms, which
@@ -143,8 +143,8 @@ given a suffix of _nng to reflect the transport mechanism
 in use.
 
 Regardless of transport mechanism supported by an RMR library,
-the RMR API will be identical, thus it is possible for an appliction
-to shift mechanisms simply by referencing a differnt library (should
+the RMR API will be identical, thus it is possible for an application
+to shift mechanisms simply by referencing a different library (should
 multiple RMR libraries become available).
 
 

diff --git a/README b/README
index d2ad917..757b115 100644 (file)
--- a/README
+++ b/README
@@ -51,15 +51,15 @@ the need for the suffix has been eliminated (existing files were not changed).
 
 External Names
 All externally facing function names and constants will start with rmr_ or
-RMR_ repsectively (RIC Message Router).    For the time being, there is a
+RMR_ respectively (RIC Message Router).    For the time being, there is a
 set of mappings from the old uta_* names to rmr_* names. The user code must
-define UTA_COMPAT to have these ensbled.
+define UTA_COMPAT to have these enabled.
 
 Internal Names
-Internal (static) functions have no mandiated convention. There are some
+Internal (static) functions have no mandated convention. There are some
 names which are prefixed with uta_.  These are left over from the original
-prototype libray which had the name Uta.  The uta_ prefixes were mostly on
-functions which were iniitally external, but were pulled back for this release.
+prototype library which had the name Uta.  The uta_ prefixes were mostly on
+functions which were initially external, but were pulled back for this release.
 
 
 
@@ -67,8 +67,8 @@ Requirements
 To build the RMR libraries, NNG must be installed, or the external references
 in the source tree must be used to pull and build the NNG library. It might
 be necessary to alter the values of C_INCLUDE_PATH,  LD_LIBRARY_PATH, or
-LIBRARY_PATH to reflect the instalation location when the installed version
-ot NNG is being used.
+LIBRARY_PATH to reflect the installation location when the installed version
+of NNG is being used.
 
 To install see the instructions on their html sites:
        https://github.com/nanomsg/nng
@@ -81,17 +81,17 @@ The script ../test/unit_test.ksh should be used for running unit tests. With no
 parameters it will attempt to build any file in this directory which has the
 name *_test.c.  Build is attempted with either mk or make and enables the
 necessary compiler flags to support coverage output (gcov).  Once built, the
-test programme is executed and if the return code is success (0), the
+test program is executed and if the return code is success (0), the
 coverage data is interpreted.
 
-The test programmes may make use of ../test/tools.c which provide simple
-validation check functions.  These programmes shouild also directly include
+The test programs may make use of ../test/tools.c which provide simple
+validation check functions.  These programs should also directly include
 the module(s) under test.  This ensures that they are not linked, and are
 compiled with the proper coverage flags. In addition, it allows modules that
 are not under test to be linked from the archive and (most importantly) not
 reported on from a coverage perspective. In cases where two modules depend on
 each other, and are static functions, they will need to be tested from a single
-unit test programme (see the rt_tool test programme).
+unit test program (see the rt_tool test program).
 
 It might be necessary to write a higher level test driver as some of the modules
 (e.g. route table) have threaded daemons which might not be easy to drive