iox-#2305 Fix typos across the project

BUILD.bazel

@@ -58,7 +58,7 @@ alias(
     visibility = ["//visibility:public"],
 )
 
-# Execute `bazel run //:buildifier` to fix formating of all starlark files in the workspace
+# Execute `bazel run //:buildifier` to fix formatting of all starlark files in the workspace
 buildifier(
     name = "buildifier",
     verbose = True,

CONTRIBUTING.md

@@ -205,7 +205,7 @@ A good example for code formatting and doxygen structure can be found in [swe_do
 ### External dependencies
 
 External dependencies such as the [STL](https://en.wikipedia.org/wiki/Standard_Template_Library) or
-other libaries shall be kept to a minium for `iceoryx_posh` and `iceoryx_hoofs`. If you think a new dependency is
+other libraries shall be kept to a minimum for `iceoryx_posh` and `iceoryx_hoofs`. If you think a new dependency is
 necessary, do the following:
 
 1. Contact the maintainers beforehand by opening an issue to discuss the necessity

doc/design/diagrams/iceoryx_components_diagram_v3_0_0.puml

@@ -48,7 +48,7 @@ package iceoryx_hoofs  {
       component Primitives <<module>>
       component Buffers <<module>>
       component "Inter-process communication" <<module>>
-      component "Threads & sychronisation" <<module>>
+      component "Threads & synchronisation" <<module>>
       component "Generalized design patterns & abstractions" <<module>>
       component Reporting <<module>>
       component Time <<module>>

doc/design/draft/service-discovery.md

@@ -80,7 +80,7 @@ change in the service registry and to transmit the service discovery registry. T
 
 Pro:
 
-* Simple and consistent user API for both event-based and sychronous requests
+* Simple and consistent user API for both event-based and synchronous requests
   * Filtering for `findService` could be done inside the new class
 * No need for a change counter as ABA problem solved by POSH mechanisms
 * Not just delta of service registry is transmitted, but complete service registry info
@@ -96,7 +96,7 @@ Con:
 Note:
 
 * To avoid any out of memory issues with custom user-configured mempools or access rights problems, the publisher shall
-write into the `iceoryx_managment` segment (same applies for the introspection publishers)
+write into the `iceoryx_management` segment (same applies for the introspection publishers)
 
 ##### Alternative E: Introduce new StatusPort/ConfigPort/BroadcastPort
 
@@ -117,7 +117,7 @@ only need read access and not write access
 * Fast data transport by using shared memory
 * Could replace `InterfacePort`s
 * Not just delta of service registry is transmitted, but complete service registry info
-* Simple and consistent user API for both event-based and sychronous requests
+* Simple and consistent user API for both event-based and synchronous requests
   * Filtering for `findService` could be done inside the new class
 
 Con:

doc/design/error_reporting.md

@@ -362,7 +362,7 @@ int resultOrAbort(int x)
 {
     auto result = algorithm(x);
 
-    // if a result was returned, we know that no error has occured
+    // if a result was returned, we know that no error has occurred
     return result;
 };
 ```

doc/design/listener.md

@@ -205,14 +205,14 @@ Listener       Event_t                  Triggerable
     attached to the Triggerable so that it can notify the Listener/WaitSet via
     the underlying `ConditionNotifier` with `TriggerHandle::notify()`.
     The cleanup task is performed by the `m_resetCallback` so that the
-    Triggerable has no dependencies to any Notifyable.
+    Triggerable has no dependencies to any Notifiable.
 
 #### Condition Variable
 
 The `ConditionListener` and `ConditionNotifier` are two different interfaces to
 the same class which state is stored in the `ConditionVariableData` class. The
 intention of the separation is to provide one side (e.g. Triggerable) only
-an API to notify the Notifyable (e.g. Listener) whereas the Notifyable can only
+an API to notify the Notifiable (e.g. Listener) whereas the Notifiable can only
 wait on events. So the contract is reflected in the design.
 
 - **Problem:** Since the Listener reacts on events and not states it requires

doc/design/lockfree_queue.md

@@ -133,7 +133,7 @@ we increase the cycle every n pushes (or pops), but the numbers representing the
 
 **Claim:** The queue push and pop operations are lock-free.
 
-1. Push operations cannot block pop operaions arbitrarily long and vice versa.
+1. Push operations cannot block pop operations arbitrarily long and vice versa.
 2. Furthermore, between concurrent pushes and pops one of each type always succeeds in a finite amount of time.
 
 **Proof sketch:**
@@ -146,7 +146,7 @@ we increase the cycle every n pushes (or pops), but the numbers representing the
 
 Therefore pushes and pops do not interfere to block each other.
 
-Push operatios can block other push operations and pop operations other pop operations due to potential starvation,
+Push operations can block other push operations and pop operations other pop operations due to potential starvation,
 but there will always be one operation that will complete (and therefore progress). This progress implies that the queue is lock-free.
 
 Note that there is no fairness guarantee. In principle the same push thread or pop thread might always succeed but in practice this is unlikely.

doc/website/FAQ.md

@@ -12,7 +12,7 @@ Check the `--shm-size` flag of the docker container. Does the container provide
 
 ## How can I find out if RouDi is running?
 
-RouDi uses a file locking machanism to ensure that only one RouDi instance is running at a time. For that RouDi
+RouDi uses a file locking mechanism to ensure that only one RouDi instance is running at a time. For that RouDi
 creates and locks `/tmp/roudi.lock`. The file exists also also when RouDi is not running. Try locking this file,
 if this fails RouDi is running.
 
@@ -124,7 +124,7 @@ target_link_options(single_process BEFORE PRIVATE /STACK:3500000)
 
 For other platforms apply other flags or solutions.
 
-### CI fails but error is locally not reproducable
+### CI fails but error is locally not reproducible
 
 One can use `tools/scripts/ice_env.sh` to create an iceoryx development environment
 with a configuration very similar to the CI target.

doc/website/advanced/configuration-guide.md

@@ -168,7 +168,7 @@ The TOML config file can be passed to RouDi with the `-c` command-line option.
 ./iox-roudi -c /absolute/path/to/config/file.toml
 ```
 
-This is an examplary config file with format version 1:
+This is an exemplary config file with format version 1:
 
 ```TOML
 [general]

doc/website/concepts/architecture.md

@@ -36,7 +36,7 @@ This section describes the namespaces of the core library.
 protocol, which is used by `iceoryx_posh` to connect and discover `popo::Publisher` and `popo::Server`.
 * `mepoo`: The namespace memory pool contains all memory-related classes. For example the `MemoryManager` or `SharedPointer`.
 * `version`: The namespace version contains ABI compatibilities checks.
-* `build`: The namespace build contains certain maximium values which can be changed before compilation.
+* `build`: The namespace build contains certain maximum values which can be changed before compilation.
 
 #### Gateway library
 

doc/website/getting-started/installation.md

@@ -102,7 +102,7 @@ Alternatively, `C:\Program Files (x86)\Microsoft Visual Studio\2022\Community\VC
 
 #### Setup for MinGW
 
-`MinGW` can also be used to build iceoryx on Windows. The easist way to do this is to use `chocolatey`.
+`MinGW` can also be used to build iceoryx on Windows. The easiest way to do this is to use `chocolatey`.
 
 ```powershell
 choco install -y mingw --version=10.3.0

doc/website/getting-started/overview.md

@@ -296,12 +296,12 @@ or clients. This way we can immediately wake up when data is available and avoid
 is available.
 
 One typical use case is to create a WaitSet, attach multiple subscribers and/or clients and user triggers and then
-wait until one or many of the attached objects signal an event. If this happens one receives a list of all occured
+wait until one or many of the attached objects signal an event. If this happens one receives a list of all occurred
 events called `notificationVector`. This makes it possible to collect data directly from the subscriber or client
 when it signals the WaitSet that new data or a new response is available.
 
 The WaitSet uses the [reactor pattern](https://en.wikipedia.org/wiki/Reactor_pattern) and is informed with a push
-strategy that one of the attached events occured at which it informs the user.
+strategy that one of the attached events occurred at which it informs the user.
 
 For more information on how to use the WaitSet see our
 [WaitSet examples](../../../iceoryx_examples/waitset).

iceoryx_binding_c/include/iceoryx_binding_c/config.h

@@ -85,7 +85,7 @@ uint32_t iox_cfg_no_user_header_alignment(void);
 /// runtime
 uint32_t iox_cfg_max_process_number(void);
 
-/// @brief returns the maximum number of services that are supported byt the service registry
+/// @brief returns the maximum number of services that are supported by the service registry
 uint32_t iox_cfg_service_registry_capacity(void);
 
 /// @brief returns the maximum number of services a findservice call can return

iceoryx_binding_c/include/iceoryx_binding_c/notification_info.h

@@ -62,7 +62,7 @@ bool iox_notification_info_does_originate_from_server(iox_notification_info_t co
 /// @brief does the notification originate from a certain service discovery
 /// @param[in] self handle to notification info
 /// @param[in] serviceDiscovery handle to serviceDiscovery in question
-/// @return true if the notifiaction originates from the service discovery, otherwise false
+/// @return true if the notification originates from the service discovery, otherwise false
 bool iox_notification_info_does_originate_from_service_discovery(iox_notification_info_t const self,
                                                                  iox_service_discovery_t const serviceDiscovery);