Fix references and label to Weimer2023

Signed-off-by: Thomas Nyman <[email protected]>

Author: thomasnyman

docs/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.md

@@ -389,7 +389,7 @@ Make the compiler treat all or specific warning diagnostics as errors.
 
 The blanket form, `-Werror` without a selector, treats all warnings as errors and can be used to implement a zero-warning policy during development. However, we recommend developers to omit the blanket form when distributing source code as it creates a dependency on specific toolchain vendors and versions [^Johnston17]. If necessary, such toolchain dependencies, i.e., which compiler version(s) the project is expected to work with, should be clearly noted in the project documentation or the build environment should be completely captured, e.g., via container recipes. However, it's better to ensure that source code is not so dependent on a specific toolchain version.
 
-The selective form, `-Werror=`*`<warning-flag>`* (note the selector), can be used for refined warnings-as-error control without introducing a blanket zero-warning policy. This is beneficial to ensure that certain undesirable constructs or defects *never* occur in produced builds. The selective form does *not* introduce a dependency on the toolchain or version if the corresponding warning is for a specific construct. For example, developers can decide to promote warnings that indicate interference with OS defense mechanisms (e.g., `-Werror=trampolines`), undefined behavior (e.g., `-Werror=return-type`), or constructs associated with software weaknesses (e.g., `-Werror=conversion`) to errors. Using a set of selecting form `-Werror` flags can help ensure that the software is ported to and correctly uses more modern versions of their language (and avoids using more risky or problematic constructs) [^Weimer2023].
+The selective form, `-Werror=`*`<warning-flag>`* (note the selector), can be used for refined warnings-as-error control without introducing a blanket zero-warning policy. This is beneficial to ensure that certain undesirable constructs or defects *never* occur in produced builds. The selective form does *not* introduce a dependency on the toolchain or version if the corresponding warning is for a specific construct. For example, developers can decide to promote warnings that indicate interference with OS defense mechanisms (e.g., `-Werror=trampolines`), undefined behavior (e.g., `-Werror=return-type`), or constructs associated with software weaknesses (e.g., `-Werror=conversion`) to errors. Using a set of selecting form `-Werror` flags can help ensure that the software is ported to and correctly uses more modern versions of their language (and avoids using more risky or problematic constructs)[^Weimer2023].
 
 Zero-warning policies can also be enforced at CI level. CI-based zero- or bounded-warning policies are often preferable, for the reasons explained above, and because they can be expanded beyond compiler warnings. For example, they can also include warnings from static analysis tools or generate warnings when `FIXME` and `TODO` comments are found.
 
@@ -417,7 +417,7 @@ The `-Werror=implicit`, `-Werror=incompatible-pointer-types`, and `-Werror=int-c
 - Conversion between pointers that have incompatible types.
 - Implicit integer to pointer and pointer to integer conversions.
 
-Using these options will make the compiler treat the corresponding obsolete construsts as errors regardless of the language standard the compiler is instructed to follow. GCC 14[^gcc-porting-to-14] and Clang 15[^clang-release-notes-15] disable support for these legacy language constructs by default so enabling these options will also prepare the codebase for transitioning to these and later compilers. Some Linux distributions, such as Fedora[^Weimer23], are enforcing the use of the these options when building software for distribution. We recommend developers adopt the options, as enabling them may require may require non-trivial changes to the source code in codebases that rely on the obsolete constructs.
+Using these options will make the compiler treat the corresponding obsolete construsts as errors regardless of the language standard the compiler is instructed to follow. GCC 14[^gcc-porting-to-14] and Clang 15[^clang-release-notes-15] disable support for these legacy language constructs by default so enabling these options will also prepare the codebase for transitioning to these and later compilers. Some Linux distributions, such as Fedora[^Weimer2023], are enforcing the use of the these options when building software for distribution. We recommend developers adopt the options, as enabling them may require may require non-trivial changes to the source code in codebases that rely on the obsolete constructs.
 
 Note that the list of options indicated here do not capture a complete list of removed features. Some changes to the expected changes to compiler default cannot be previewed using compiler flags but require instructing the compiler to support a specific langauge standard (C99 or later dialect) and to give errors whenever the base standard requires a diagnostic[^gcc-pedantic-errors].
 
@@ -431,7 +431,7 @@ Some tools, such as `autoconf`, automatically determine what the compiler suppor
 
 [^clang-release-notes-15]: LLVM team, [Clang 15.0.0 Release Notes](https://releases.llvm.org/15.0.0/tools/clang/docs/ReleaseNotes.html), Clang documentation, 2022-09-06.
 
-[^Weimer23]: Weimer, Florian, [Porting to Modern C](https://fedoraproject.org/wiki/Changes/PortingToModernC), Fedora Project Wiki, 2023-12-22.
+[^Weimer2023]: Weimer, Florian, [Porting to Modern C](https://fedoraproject.org/wiki/Changes/PortingToModernC), Fedora Project Wiki, 2023-12-22.
 
 [^gcc-pedantic-errors]: GCC team, [Using the GNU Compiler Collection (GCC): Warning Options: `-pedantic-errors`](https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-pedantic-errors-1), GCC Manual, 2023-07-27.