Fix typos in docs, comments and error message text

CMakeLists.txt

@@ -48,7 +48,7 @@ project(OSAL C)
 # part of the open source release.
 # CAUTION: The API between the OSAL and the low level implementation and/or BSP
 # is not stabilized, and may change with every OSAL release.  No attempt is made
-# to provide backward compatibility with to external sources.
+# to provide backward compatibility with external sources.
 set(OSAL_EXT_SOURCE_DIR "$ENV{OSAL_EXT_SOURCE_DIR}"
     CACHE PATH "External source directory to check for additional OS/BSP implementations")
 
@@ -106,7 +106,7 @@ add_subdirectory(ut_assert)
 
 
 # OSAL_SYSTEM_BSPTYPE indicate which of the BSP packages
-# to build.  These is required and must be defined. Confirm that this exists
+# to build.  This is required and must be defined. Confirm that this exists
 # and error out now if it does not.
 if (NOT DEFINED OSAL_SYSTEM_BSPTYPE)
   message(FATAL_ERROR "OSAL_SYSTEM_BSPTYPE must be set to the appropriate BSP")

Makefile.sample

@@ -83,13 +83,13 @@ $(FILETGTS):
 	$(MAKE) -C $(O) $(@)
 endif
 
-# The "prep" step requires extra options that are specified via enviroment variables.
+# The "prep" step requires extra options that are specified via environment variables.
 # Certain special ones should be passed via cache (-D) options to CMake.
 # These are only needed for the "prep" target but they are computed globally anyway.
 #
-# Note this simple makefile just builds for one target, could trivally manage
+# Note this simple makefile just builds for one target, could trivially manage
 # multiple targets by changing build directory.  More complex target
-# list examples are provide by cFE..
+# list examples are provided by cFE.
 PREP_OPTS := -DOSAL_SYSTEM_BSPTYPE=$(BSPTYPE) -DINSTALL_TARGET_LIST=.
 
 ifneq ($(INSTALLPREFIX),)

README.md

@@ -5,7 +5,7 @@
 
 This repository contains NASA's Operating System Abstraction Layer (OSAL), which is a framework component of the Core Flight System.
 
-This is a collection of abstractio APIs and associated framework to be located in the `osal` subdirectory of a cFS Mission Tree. The Core Flight System is bundled at <https://github.com/nasa/cFS>, which includes build and execution instructions.
+This is a collection of abstraction APIs and associated framework to be located in the `osal` subdirectory of a cFS Mission Tree. The Core Flight System is bundled at <https://github.com/nasa/cFS>, which includes build and execution instructions.
 
 The autogenerated OSAL user's guide can be viewed at <https://github.com/nasa/cFS/blob/gh-pages/OSAL_Users_Guide.pdf>.
 
@@ -134,14 +134,14 @@ See <https://github.com/nasa/osal/pull/1050> and <https://github.com/nasa/cFS/pu
 
 ### Development Build: v5.1.0-rc1+dev417
 
-- Fixes infinite loop  in `UtPrintx()`. Adds the data's memory address to output. Note, UtPrintf displays the the file/line of the `UtPrintx` function, **not the actual test location**; it is better to call `UT_BSP_DoText` directly.
+- Fixes infinite loop  in `UtPrintx()`. Adds the data's memory address to output. Note, UtPrintf displays the file/line of the `UtPrintx` function, **not the actual test location**; it is better to call `UT_BSP_DoText` directly.
 - Adds `OS_SocketShutdown()` API wrapper around BSD's socket shutdown() API. This allows a data transfer of a stream socket to be gracefully shut down prior to socket closure.
 - See osal <https://github.com/nasa/osal/pull/979> and <https://github.com/nasa/cFS/pull/252>
 
 ### Development Build: v5.1.0-rc1+dev411
 
 - [docs] Clarifies that that zero will be returned on EOF condition in the API documentation for OS_read/write/TimedRead/TimedWrite. In the case of the timed API calls, the `OS_ERR_TIMEOUT` status code will be returned if the timeout expired without the handle becoming readable/writable during that time.
-- Addresses a shortcomings in the UT Assert hook functions. Namely the assumed return type of int32 which is not always the case.
+- Addresses shortcomings in the UT Assert hook functions. Namely the assumed return type of int32 which is not always the case.
 - Adds the concept of a "handler" function to UT assert to replace hard-coded custom logic in UT assert. A handler is the custom logic that exists between the hook function and the return to the stub caller. The handler is directly responsible for setting all outputs.
 - Adds a script to auto-generate stub functions that match this pattern. Given an API header file, the script extracts
 the declarations, and generates a source file with stub definitions that rely on a separate handler to deal with the needed outputs.
@@ -156,7 +156,7 @@ the declarations, and generates a source file with stub definitions that rely on
 ### Development Build: v5.1.0-rc1+dev393
 
 - Changes parameter names to avoid collisions. Renames `access` as `access_mode` in `osapi-file.h`. Renames `time` as `TimeSp` in `os-impl-posix-gettime.c`.
-- Deletes the broken RTEMS `os-impl-shell.c` file so so OSAL builds with `OSAL_CONFIG_INCLUDE_SHELL=true`. RTEMS will always report `OS_ERR_NOT_IMPLEMENTED`.
+- Deletes the broken RTEMS `os-impl-shell.c` file so OSAL builds with `OSAL_CONFIG_INCLUDE_SHELL=true`. RTEMS will always report `OS_ERR_NOT_IMPLEMENTED`.
 - See <https://github.com/nasa/osal/pull/967> and <https://github.com/nasa/cFS/pull/248>
 
 ### Development Build: v5.1.0-rc1+dev387
@@ -172,7 +172,7 @@ the declarations, and generates a source file with stub definitions that rely on
 ### Development Build: v5.1.0-rc1+dev378
 
 - Replaces nonstandard header file block comments and include guards. No behavior changes
-- Removes `CLOCK_MONOTONIC` as the osal colck source since PSP no longer needs it. `OS_GetLocalTime()` and `OS_SetLocalTime()` will work as described.
+- Removes `CLOCK_MONOTONIC` as the osal clock source since PSP no longer needs it. `OS_GetLocalTime()` and `OS_SetLocalTime()` will work as described.
 - Replaces `shellName` with a specific `localShellName` that can be polled safely and changes its type to a char of `OS_MAX_API_NAME` length for safety.
 - See <https://github.com/nasa/osal/pull/951> and <https://github.com/nasa/cFS/pull/238>
 
@@ -182,7 +182,7 @@ the declarations, and generates a source file with stub definitions that rely on
 - Applies minor code and documentation cleanup: white space, typos, etc.
 - Adds test to get full coverage of vxworks in `os-impl-bsd-socket.c` resulting in full line coverage for OSAL
 - Adds more descriptive return codes if `OS_SymbolTableDump_Impl` does not do what is expected. Adds a new error `OS_ERR_OUTPUT_TOO_LARGE` if the size limit was insufficient. Return `OS_ERROR` if an empty file was written - this likely indicates some fundamental issue with the VxWorks symbol table. Returns `OS_ERR_NAME_TOO_LONG` if one of the symbol names was too long. Improves unit test to check for/verify these responses.
-- Removes the unneeded `OS_TaskRegister()` and all references to it in code, tests, and documentation. No impact to behavior, but does affect API and has depenedencies
+- Removes the unneeded `OS_TaskRegister()` and all references to it in code, tests, and documentation. No impact to behavior, but does affect API and has dependencies
 - Removes unused `-SCRIPT_MODE` flag in cmake
 - Remove comparison between `osal_id_t` and `integers` to use the provided comparison function, `OS_ObjectIdDefined()`. System builds and runs again when using a type-safe/non-integer osal_id_t type.
 - See <https://github.com/nasa/osal/pull/927>
@@ -379,7 +379,7 @@ OS_MutSemTake():216:WARNING: Task 65547 taking mutex 327685 while owned by task
 
 ### Development Build: v5.1.0-rc1+dev60
 
-- Appliy standard formating, whitespace-only changes
+- Apply standard formatting, whitespace-only changes
 - See <https://github.com/nasa/osal/pull/627>
 
 ### Development Build: v5.1.0-rc1+dev55
@@ -407,7 +407,7 @@ OS_MutSemTake():216:WARNING: Task 65547 taking mutex 327685 while owned by task
 
 ### Development Build: v5.1.0-rc1+dev34
 
-- Move this existing function into the public API, as it is performs more verification than the OS_ConvertToArrayIndex function.
+- Move this existing function into the public API, as it performs more verification than the OS_ConvertToArrayIndex function.
 - The C library type is signed, and this makes the result check work as intended.
 - See <https://github.com/nasa/osal/pull/596>
 
@@ -453,7 +453,7 @@ a common location for additional table-deletion-related logic.
 - No impact to current unit testing which runs UT assert as a standalone app. Add a position independent code (PIC) variant of the ut_assert library, which can be dynamically loaded into other applications rather than running as a standalone OSAL application. This enables loading
 UT assert as a CFE library.
 - Unit tests pass on RTEMS.
-- Resolve inconsistency in how the stack size is treated across different OS implemntations. With this change the user-requested size is passed through to the underlying OS without an enforced minimum. An additional sanity check is added at the shared layer to ensure that the stack size is never passed as 0.
+- Resolve inconsistency in how the stack size is treated across different OS implementations. With this change the user-requested size is passed through to the underlying OS without an enforced minimum. An additional sanity check is added at the shared layer to ensure that the stack size is never passed as 0.
 - Update Licenses for Apache 2.0
 - See <https://github.com/nasa/osal/pull/521>
 

SECURITY.md

@@ -6,7 +6,7 @@ To report a vulnerability for the OSAL subsystem please [submit an issue](https:
 
 For general cFS vulnerabilities please [open a cFS framework issue](https://github.com/nasa/cfs/issues/new/choose) and see our [top-level security policy](https://github.com/nasa/cFS/security/policy) for additional information.
 
-In either case please use the "Bug Report" template and provide as much information as possible. Apply appropraite labels for each report. For security related reports, tag the issue with the "security" label.
+In either case please use the "Bug Report" template and provide as much information as possible. Apply appropriate labels for each report. For security related reports, tag the issue with the "security" label.
 
 ## Testing
 

default_config.cmake

@@ -30,7 +30,7 @@
 # either in the OSAL or the application which invoked OSAL.
 #
 # If set FALSE (default), then the OSAL bugcheck macro will evaluate its
-# boolean conditional and generate an action if that conditional evaulates
+# boolean conditional and generate an action if that conditional evaluates
 # false.  (The specific action to take is configured via a different
 # directive -- see OSAL_CONFIG_BUGCHECK_STRICT).
 #
@@ -73,7 +73,7 @@ set(OSAL_CONFIG_BUGCHECK_STRICT                  FALSE)
 #
 # Whether to include the Network API
 #
-# If set TRUE, the the socket abstraction (if applicable on the platform)
+# If set TRUE, the socket abstraction (if applicable on the platform)
 # will be included.  If set FALSE, then all calls to the network API will
 # return OS_ERR_NOT_IMPLEMENTED.
 #
@@ -276,12 +276,12 @@ set(OSAL_CONFIG_MAX_FILE_NAME           20
     CACHE STRING "Maximum Length of file names"
 )
 
-# Maximum length for an virtual path name (virtual directory + file)
+# Maximum length for a virtual path name (virtual directory + file)
 set(OSAL_CONFIG_MAX_PATH_LEN            64
     CACHE STRING "Maximum Length of path names"
 )
 
-# Maximum length allowed for a object (task,queue....) name
+# Maximum length allowed for an object (task,queue....) name
 set(OSAL_CONFIG_MAX_API_NAME            20
     CACHE STRING "Maximum Length of resource names"
 )

docs/OSAL-Configuration-Guide.md

@@ -76,7 +76,7 @@ The following sections provide instructions on how to:
 
 -   Configure the build directory for an OSAL application
 
--   Configure a OSAL Application
+-   Configure an OSAL Application
 
 -   Build the OSAL Application
 
@@ -135,7 +135,7 @@ Most parameters set upper bounds on the number of OS objects that can be created
 the OSAL keeps track of allocated OS objects using fixed size tables.
 
 If customization is desired, one should not modify the `default_config.cmake` file directly,
-but rather provide a alternative values by one of the override methods:
+but rather provide alternative values by one of the override methods:
 
 - If configuring OSAL as a standalone build for testing, values for options can be
   specified as `-D` options on the cmake command.  This is a common method of specifying
@@ -486,13 +486,13 @@ software to remain portable.
 There are a few ways to map these host file systems to OSAL file
 systems:
 
--   **Map existing target file systems to a OSAL path**. This is one of
+-   **Map existing target file systems to an OSAL path**. This is one of
 the most common ways to map the Non-Volatile disk to the OSAL. The OSAL
 relies on the target OS to create/mount a file system and it simply is
 given a mapping to the disk to allow the OSAL to access it.
 
 -   **Create EEPROM/Flash/ATA File systems**. The OSAL has the ability
-on some targets to format or initialize a EEPROM or ATA disk device.
+on some targets to format or initialize an EEPROM or ATA disk device.
 This is less commonly used.
 
 -   **Create RAM File Systems**. The OSAL can create RAM disks on the
@@ -510,7 +510,7 @@ mappings via API calls during its startup.  This may be done any time after call
 `OS_API_Init()`.
 
 For example, for Core Flight System (cFS) configurations that require persistent
-storage to be provided under a virual directory called `/cf`, the platform-specific
+storage to be provided under a virtual directory called `/cf`, the platform-specific
 CFE PSP layer configures the mapping in an appropriate manner by calling
 the `OS_FileSysAddFixedMap()` API during its OS_Application_Startup() implementation.
 
@@ -633,14 +633,14 @@ qemu-system-i386 -m 128 -no-reboot -display none -serial stdio \
 ```
 
 Where `<image>.exe` refers to any of the test programs or applications
-that are provided with OSAL.  This command puts the virual console on
+that are provided with OSAL.  This command puts the virtual console on
 the same terminal where the QEMU emulator is started.  The program
 should run automatically after the kernel boots.  The system may be
 stopped by issuing the "shutdown" command at the shell, or by pressing
 the CTRL+A followed by CTRL+C which terminates QEMU.
 
 
-## Generc Linux Platform
+## Generic Linux Platform
 
 The OSAL can run on many Linux distributions. Testing is done with currently
 supported Ubuntu LTS versions (up through 20.04 at the time of the current
@@ -690,7 +690,7 @@ each OSAL subsystem is specially compiled with special flags to enable
 profiling (to track line and branch coverage) and linked with _stub_
 implementations of all other dependencies.  This way, test cases can
 trigger error paths from library calls that would otherwise not be possible
-in a black box test enviornment.
+in a black box test environment.
 
 These test programs are executed just as any other application program.
 
@@ -720,7 +720,7 @@ the test programs will be copied to the output location/staging area.
 ### Option 1: Execute single test directly from a build tree
 
 The tests can be executed directly in-place in the build directory.  This method often useful
-when debugging, as the exectuable can also be run in a debugger (i.e. gdb) this way.
+when debugging, as the executable can also be run in a debugger (i.e. gdb) this way.
 
 The following example executes the task subsystem coverage test for the shared layer, but any
 other test can be run in a similar fashion.

docs/src/osal_fs.dox

@@ -74,8 +74,8 @@ instance, the path of the file that the file descriptor points to can be easily
  to determine statistics for a task, or the entire system. This information can all
  be retrieved with a single API, OS_FDGetInfo.
 
- All of possible file system calls are not implemented.  "Special" files requiring OS
- specific control/operations are by nature not portable.  Abstraction in this case is
+ All of the possible file system calls are not implemented.  "Special" files requiring
+ OS specific control/operations are by nature not portable.  Abstraction in this case
  is not possible, so the raw OS calls should be used (including open/close/etc).  Mixing
  with OSAL calls is not supported for such cases.  #OS_TranslatePath is available to
  support using open directly by an app and maintain abstraction on the file system.

src/bsp/generic-linux/src/bsp_start.c

@@ -136,7 +136,7 @@ void OS_BSP_Unlock_Impl(void)
     }
     else
     {
-        /* Restore previous cancelability state */
+        /* Restore previous cancellability state */
         pthread_setcancelstate(OS_BSP_GenericLinuxGlobal.AccessCancelState, NULL);
     }
 }
@@ -212,7 +212,7 @@ int main(int argc, char *argv[])
      * Note that the first argument (0) is the command name.  The
      * first "real" argument is at position 1.
      *
-     * However this still needs to pass it through as the appliction
+     * However this still needs to pass it through as the application
      * might still want to use library "getopt" and this expects the
      * first parameter to be this way.
      */

src/bsp/generic-vxworks/src/bsp_start.c

@@ -108,7 +108,7 @@ int OS_BSPMain(void)
 
     if (OS_BSP_GenericVxWorksGlobal.AccessMutex == (SEM_ID)0)
     {
-        BSP_DEBUG("semMInitalize: errno=%d\n", errno);
+        BSP_DEBUG("semMInitialize: errno=%d\n", errno);
     }
 
     /*

src/bsp/pc-rtems/src/bsp_start.c

@@ -385,7 +385,7 @@ rtems_task Init(rtems_task_argument ignored)
 /* configuration information */
 
 /*
-** RTEMS OS Configuration defintions
+** RTEMS OS Configuration definitions
 */
 #define TASK_INTLEVEL 0
 #define CONFIGURE_INIT

src/bsp/shared/inc/bsp-impl.h

@@ -113,7 +113,7 @@ extern OS_BSP_GlobalData_t OS_BSP_Global;
 
     Purpose: Get exclusive access to a BSP-provided service or object
 
-             Useful in conjuction with console output functions to avoid strings
+             Useful in conjunction with console output functions to avoid strings
              from multiple tasks getting mixed together in the final output.
 
  ------------------------------------------------------------------*/

src/os/inc/osapi-common.h

@@ -150,7 +150,7 @@ int32 OS_API_Init(void);
  *
  * Normally for embedded applications, the OSAL is initialized after boot and will remain
  * initialized in memory until the processor is rebooted.  However for testing and
- * developement purposes, it is potentially useful to reset back to initial conditions.
+ * development purposes, it is potentially useful to reset back to initial conditions.
  *
  * For testing purposes, this API is designed/intended to be compatible with the
  * UtTest_AddTeardown() routine provided by the UT-Assert subsystem.