C & C++

Using the storage specifier static inside an anonymous namespace is redundant. The anonymous namespace already limits the visibility of definitions to a single translation unit. To fix the issue, simply remove the static specifier from the definitions inside the anonymous namespace. This will make the code more concise.

Fall-through in switch cases is often considered risky. Hence consider adding an unconditional break for each switch clause.

Accessing static member variables through class instances can give the impression that the member belongs to the instance, which is incorrect. This can lead to confusion and make the code harder to understand and maintain. To fix this issue, simply replace the instance access with the class name followed by the member variable. This clearly indicates that the member is a static member of the class and avoids any confusion.

Pointer offset(or any other arithmetic operation) on a pointer casted to a different type (than its original type) is risky and can result in undefined behaviour. The reason for such behaviour is that the memory alignment may change for types on every targeted platform.

Copying an object is an expensive operation, especially if the type of the object is not trivial to copy. To avoid creating an unnecessary copy of such object, use const references.

The analyser has found a local variable that can't be automatically moved. The reason for this behavior is the constness of the variable. Consider declaring the variable without the qualifier const.

Using enum as a bitmask or flags is only valid if the members are only assigned values in the power of twos.

Manually appending a significant number of elements to a std::vector without reserving the memory upfront can cause performance issues as the memory needs to be reallocated and copied every time the std::vector's size increases. This can be costly if many items need to be pushed into the std::vector. Consider using the std::vector::reserve() function to preallocate memory for the std::vector before a loop containing a std::vector::push_back.

While writing data to a buffer, the program can overrun the buffer's boundary and overwrite adjacent memory locations. These can either cause a crash if the memory region is inaccessible to the process for writing, or in the worst case produce a vulnerability to overwrite parts of the memory with untrusted user code.

The pthread_* or posix_* functions (except posix_openpt) always return a positive values. When the functions mentioned above are used in negative integer range checks, the expression will always be resolved to false as these functions return either zero (on success) or a positive err-no on failure.

Improper seeding or failing to seed a pseudorandom number generator (PRNG) can lead to vulnerabilities, especially in security protocols, as an attacker can predict the sequence of random numbers that will be generated in future runs of the program. The solution is to properly seed the PRNG with an initial seed value that is not predictable or controllable by an attacker to ensure that a different sequence of random numbers is generated each time the program runs.

This issue applies only to algorithmic PRNGs that can be seeded, as true random number generators that rely on hardware to produce completely unpredictable results do not need to be and cannot be seeded.

Identifiers with typographically ambiguous names can be hard to read and adds unnecessary responsibility on the developer to be careful with the exact identifiers they are using.

Having identifiers unintentionally shadowed from the outer scope by the inner scope can possibly lead to bugs in code.

Consider using unique identifier names.

Default case provides switch statements with fallback, and in general is a good to have. Hence consider adding default case to switch.

Using a semicolon right after the conditional statement (for example an if, for, while, etc.) indicates that nothing happens if the predicate is true. Though this is sometimes intentional, but at other times this might also

Classes, structs, and unions containing redundant member (field and method) access specifiers can lead to code that is more difficult to read and maintain.

Using special-meaning characters in header names can produce errors in parsing.

Consider cleaning up header names.

In C++, one can limit a declaration to the namespace to avoid name resolution conflicts. Also, a namespace declaration is not limited to a single file. This opens up the opportunity to modify the namespace introduced by the standard C++ library namely std and posix. According to the standard, such a modification is an undefined behavior. Avoid adding declaration or definition to namespace std or namespace posix.

Modifying the control variable of a for loop in its body can make the code harder to read.

Consider using a while loop, or move the modification into the for loop's update expression.

Local variable declarations with more than one variable in a single statement can lead to confusion and make the code harder to read. It is recommended to refactor the code to have one declaration per statement, with each statement on a separate line.