Fix asciidoc w.r.t. C++ (#3519)

"C++" spelled as-is can result in unexpected rendering, such as

    C++20 was released before C++17

renders as

    C20 was released before C17

Make consistent use of `[source,cpp]`.

rules/S1079/cfamily/rule.adoc

@@ -20,7 +20,7 @@ Note that the ``++%s++`` format specifier always null-terminates the string in t
 
 ==== Noncompliant code example
 
-[source,C++,diff-id=1,diff-type=noncompliant]
+[source,cpp,diff-id=1,diff-type=noncompliant]
 ----
 char buffer[10];
 scanf("%s", buffer);  // Noncompliant
@@ -30,7 +30,7 @@ If this code is given the word ``noncompliant`` as an input, ``noncomplia`` will
 
 ==== Compliant solution
 
-[source,C++,diff-id=1,diff-type=compliant]
+[source,cpp,diff-id=1,diff-type=compliant]
 ----
 char buffer[10];
 scanf("%9s", buffer);

rules/S1081/cfamily/how-to-fix-it/buffer-overflow.adoc

@@ -45,7 +45,7 @@ strcpy_s(buffer, sizeof buffer, input);
 
 === How does this work?
 
-C and C++ have a number of functions that are considered insecure because they do not perform bounds checking. Functions like ``gets`` are known to be risky. Replace these with safer alternatives that include bounds checking. For example, instead of ``gets``, use ``gets_s``.
+C and {cpp} have a number of functions that are considered insecure because they do not perform bounds checking. Functions like ``gets`` are known to be risky. Replace these with safer alternatives that include bounds checking. For example, instead of ``gets``, use ``gets_s``.
 
 The code can also checks if the size of input data is less than or equal to the size of a buffer (including the terminating null byte when dealing with strings).
 

rules/S1081/rationale.adoc

@@ -1,5 +1,5 @@
 An attacker typically provides input that exceeds the expected size. This could be through a text field in a user interface, a file that the program reads, or data sent over a network. The insecure function processes this input and places the result into a provided buffer.
-	
+
 If the input is larger than the buffer can handle, the insecure function will overwrite the memory following the buffer. This situation is known as a buffer overflow vulnerability.
 
-When using typical C or C++ functions, it's up to the developer to make sure the size of the buffer to be written to is large enough to avoid buffer overflows.
+When using typical C or {cpp} functions, it's up to the developer to make sure the size of the buffer to be written to is large enough to avoid buffer overflows.

rules/S2259/cfamily/rule.adoc

@@ -2,7 +2,7 @@ Dereferencing a null pointer results in undefined behavior.
 
 == Why is this an issue?
 
-A pointer to null, also known as a null pointer, is created by initializing a pointer object to `0`, `NULL`, or in the case of C++ `nullptr`.
+A pointer to null, also known as a null pointer, is created by initializing a pointer object to `0`, `NULL`, or in the case of {cpp} `nullptr`.
 A null pointer does neither point to an object nor to valid memory, and as a consequence dereferencing or accessing the memory pointed by such a pointer is undefined behavior.
 
 [source,c]
@@ -42,7 +42,7 @@ Finally, invoking a function pointer that holds a null value, dereferences the p
 ----
 void call() {
   void (*func)(int) = NULL; // func is a pointer to a function
-  func(10); // Noncompliant: the invocation of a null function pointer 
+  func(10); // Noncompliant: the invocation of a null function pointer
 }
 ----
 

rules/S3574/cfamily/rule.adoc

@@ -34,7 +34,7 @@ The issue is raised when explicit return types are used.
 There are a few exceptions to this rule.
 
 First, no issue is raised when the compiler is not deducing the same type by itself.
-This can happens when a conversion is requested.
+This can happen when a conversion is requested.
 
 [source,cpp]
 ----
@@ -65,7 +65,7 @@ This can have an impact on both correctness and performance.
 ----
 
 Additionally, no issues are raised when the deduction of the return type is not available.
-This is the case with C++20 coroutines in their lambda form.
+This is the case with {cpp}20 coroutines in their lambda form.
 
 [source,cpp]
 ----

rules/S5270/cfamily/rule.adoc

@@ -2,16 +2,16 @@
 
 Variadic arguments allow a function to accept any number of arguments (in this rule, we are not talking about variadic templates, but about functions with ellipses). But these arguments have to respect some criteria to be handled properly.
 
-The standard imposes some requirements on the class types that can be passed as variadic arguments, and those requirements vary according to the C++ standard version in use:
+The standard imposes some requirements on the class types that can be passed as variadic arguments, and those requirements vary according to the {cpp} standard version in use:
 
-* Before C++11, the standard only allows POD types to be used as variadic arguments.
-* In C++11, the rules are relaxed such that any class type with an eligible non-trivial copy constructor, an eligible non-trivial move constructor, or a non-trivial destructor can be used in variadic arguments.
+* Before {cpp}11, the standard only allows POD types to be used as variadic arguments.
+* In {cpp}11, the rules are relaxed such that any class type with an eligible non-trivial copy constructor, an eligible non-trivial move constructor, or a non-trivial destructor can be used in variadic arguments.
 
 The rule detects any violations of these requirements since they can trigger undefined behavior.
 
 Additionally, since using an incorrect type to access the passed parameter within the variadic function can lead to undefined behavior, the rule goes a step further and reports all cases when class types are passed as variadic arguments. The rationale is that, most likely, the user forgot to call a method on the object being passed (``std::string_view::data()`` for example) that would get a member of a built-in type.
 
-When in need to pass class types to functions that take a variable number of arguments, consider using modern type-safe alternatives like C++11 parameter packs instead of variadic functions.
+When in need to pass class types to functions that take a variable number of arguments, consider using modern type-safe alternatives like {cpp}11 parameter packs instead of variadic functions.
 
 === Noncompliant code example
 
@@ -21,7 +21,7 @@ void my_log(const char* format, ...);
 
 void f() {
   std::string someStr = "foo";
-  my_log("%s", someStr);  // Noncompliant; the c++11 standard requires types passed as variadic arguments to have a trivial copy constructor. The user probably meant to pass someStr.c_str() here
+  my_log("%s", someStr);  // Noncompliant; the C++11 standard requires types passed as variadic arguments to have a trivial copy constructor. The user probably meant to pass someStr.c_str() here
 
   std::string_view someStrView = "bar";
   my_log("%s", someStrView); // Noncompliant; the user probably meant to pass someText.data()
@@ -53,7 +53,7 @@ void f() {
 The rule doesn't report an issue in the following cases:
 
 * When the called variadic function doesn't have any non-variadic parameters. This is a common pattern when the function is used as a catch-all net for an overload set. This is also guaranteed to be safe since there is no portable to access the passed arguments.
-* When the called variadic function is known to accept a class type object as a variadic argument (e.g. the ``semctl`` system call).
+* When the called variadic function is known to accept a class type object as a variadic argument (e.g., the ``semctl`` system call).
 
 [source,cpp]
 ----

rules/S5272/cfamily/rule.adoc

@@ -27,7 +27,7 @@ Trying to access an object that has been moved-from frequently ends up in a null
 
 === Exceptions
 
-There are some C++ standard template library types such as `std::unique_ptr` for which the moved-from state is fully specified.
+There are some {cpp} standard template library types, such as `std::unique_ptr`, for which the moved-from state is fully specified.
 
 
 === Exemplary type with move operations

rules/S5487/cfamily/rule.adoc

@@ -227,7 +227,7 @@ ifdef::env-github,rspecator-view[]
 === on 13 Oct 2023, Arseniy Zaostrovnykh wrote:
 
 (Tomek's suggestion)As a further improvement possibility
-"Going the extra mile" could explain how the modern ({cpp}17, {cpp}20) std::locks are implemented so that people could reimplement them in C++11 if necessary.
+"Going the extra mile" could explain how the modern ({cpp}17, {cpp}20) std::locks are implemented so that people could reimplement them in {cpp}11 if necessary.
 
 === relates to: S5486
 

rules/S5847/cfamily/rule.adoc

@@ -25,12 +25,12 @@ include::../common/how-to-fix/rationale.adoc[]
 The following code sample is susceptible to a race condition attack because it
 checks a file exists strictly before it opens it for writing.
 
-[source,C++,diff-id=1,diff-type=noncompliant]
+[source,cpp,diff-id=1,diff-type=noncompliant]
 ----
 FILE *fopen_if_not_exists(const char *file) {
   if (access(file, F_OK) == -1 && errno == ENOENT) {
     FILE *f = fopen(file, "w"); // Noncompliant
-    
+
     return f;
   }
 
@@ -40,7 +40,7 @@ FILE *fopen_if_not_exists(const char *file) {
 
 ==== Compliant solution
 
-[source,C++,diff-id=1,diff-type=compliant]
+[source,cpp,diff-id=1,diff-type=compliant]
 ----
 FILE *fopen_if_not_exists(const char *file) {
   FILE *f = fopen(file, "wx");

rules/S6191/cfamily/rule.adoc

@@ -1,6 +1,6 @@
 == Why is this an issue?
 
-In C++, it usually does not matter how many times you access a variable as long as the variable value is the right one. However, this is not the case when the variable is in a memory region mapped to external hardware. In that case, for instance, several successive reads can yield different values (if the memory is updated by the hardware in-between), and several writes of the same value may be significant (some hardware trigger events each time a memory location is written to). 
+In {cpp}, it usually does not matter how many times you access a variable as long as the variable value is the right one. However, this is not the case when the variable is in a memory region mapped to external hardware. In that case, for instance, several successive reads can yield different values (if the memory is updated by the hardware in-between), and several writes of the same value may be significant (some hardware trigger events each time a memory location is written to).
 
 To specify that every read and write has an impact outside of the abstract machine of the language, access to a variable may be qualified as `volatile`: it will oblige the program to perform all specified reads and writes operations without optimizing anything away.
 

rules/S6391/cfamily/rule.adoc

@@ -1,6 +1,6 @@
 == Why is this an issue?
 
-Coroutines, introduced in C++20, are functions in which execution can be suspended and resumed.
+Coroutines, introduced in {cpp}20, are functions in which execution can be suspended and resumed.
 When a coroutine resumes, it takes over where it left thanks to the coroutine state.
 
 A _coroutine state_ is an object which contains all the information a coroutine needs to resume its execution correctly:

rules/S6494/cfamily/rule.adoc

@@ -3,7 +3,7 @@
 In contrast to C printf-like functions, the `std::format` family of formatting functions provides
 a safer and more robust interface for performing text formatting.
 
-Firstly, C++ formatting facilities perform validation of the format string against the type
+Firstly, {cpp} formatting facilities perform validation of the format string against the type
 of the formatted argument. If the validation fails, it is reported as a compilation error
 for the calls of `std::format` and via exception for  `std::vformat`.
 
@@ -15,7 +15,7 @@ Furthermore, `{}` can be used for any type with default format spec, which makes
 Finally, the `std::format` API can be extended to support custom types with the dedicated format specification via
 `std::formatter` specializations.
 
-This rule raises issues for calls of the `sprintf` and `snprintf` functions that can be replaced by the C++ formatting functions.
+This rule raises issues for calls of the `sprintf` and `snprintf` functions that can be replaced by the {cpp} formatting functions.
 
 === Noncompliant code example
 

rules/S6655/cfamily/rule.adoc

@@ -4,7 +4,7 @@ access for local variables and lifetime-extended temporaries.
 
 == Why is this an issue?
 
-Local variables in C++ are attached to the scope and destroyed when
+Local variables in {cpp} are attached to the scope and destroyed when
 the end of the scope is reached. Any access to a variable outside
 of their scope has undefined behavior.
 

rules/S874/cfamily/rule.adoc

@@ -2,9 +2,9 @@
 
 Most built-in bitwise operators (``++~++``, ``++>>++``, ``++>>=++``, ``++&++``, ``++&=++``, ``++^++``, ``++^=++``, ``++|++``, and ``++|=++``) have implementation-dependent results when performed on signed operands, and bitwise left shift (``++<<++`` and ``++<<=++``) has unspecified or undefined behavior when performed on negative operands.
 
-Therefore bitwise operations should not be performed on signed operands.
+Therefore, bitwise operations should not be performed on signed operands.
 
-Starting with C++20, the behaviors have been defined more accurately (negative values have to be represented using two's complement), and therefore this rule will only report an issue when the second operand of a shift operator is signed (shifting by a negative value is still undefined behavior).
+Starting with {cpp}20, the behaviors have been defined more accurately (negative values have to be represented using two's complement), and therefore this rule will only report an issue when the second operand of a shift operator is signed (shifting by a negative value is still undefined behavior).
 
 === Noncompliant code example
 
@@ -23,7 +23,7 @@ auto f(int i) {
 
 [source,cpp]
 ----
-if ( ( uint16_a | uint16_b ) == 0x1234U ) 
+if ( ( uint16_a | uint16_b ) == 0x1234U )
 if ( ~uint16_a == 0x1234U )
 
 auto f(unsigned int i) {

rules/S954/cfamily/rule.adoc

@@ -2,7 +2,7 @@
 
 To aid code readability, all the ``++#include++`` directives in a particular code file should be grouped together near the top of the file. The only items which may precede an ``++#include++`` in a file are other preprocessor directives or comments.
 
-Additionally, an ``++#include++`` may appear within an `extern "C"` block, this can be used for instance to include a C file from a C++ file.
+Additionally, an ``++#include++`` may appear within an `extern "C"` block, this can be used for instance to include a C file from a {cpp} file.
 
 
 === Noncompliant code example
@@ -22,7 +22,7 @@ int32_t i;
 #include <h1.h>
 #include <f2.h>
 extern "C" {
-#include <f3.h>    
+#include <f3.h>
 }
 
 int32_t i;