mirror of
https://github.com/github/codeql.git
synced 2026-04-29 02:35:15 +02:00
@@ -11,7 +11,7 @@ caused by an unhandled case.</p>
|
||||
|
||||
</overview>
|
||||
<recommendation>
|
||||
<p>Check that the unused static variable does not indicate a defect, for example, an unhandled case. If the static variable is genuinuely not needed,
|
||||
<p>Check that the unused static variable does not indicate a defect, for example, an unhandled case. If the static variable is genuinely not needed,
|
||||
then removing it will make code more readable. If the static variable is needed then you should update the code to fix the defect.</p>
|
||||
|
||||
</recommendation>
|
||||
|
||||
@@ -19,7 +19,7 @@ This can occur when an operation performed on the open descriptor fails, and the
|
||||
|
||||
<example>
|
||||
<p>In the example below, the <code>sockfd</code> socket may remain open if an error is triggered.
|
||||
The code should be updated to ensure that the socket is always closed when when the function ends.
|
||||
The code should be updated to ensure that the socket is always closed when the function ends.
|
||||
</p>
|
||||
<sample src="DescriptorMayNotBeClosed.cpp" />
|
||||
</example>
|
||||
|
||||
@@ -15,7 +15,7 @@ As an exception, because their purpose is usually obvious, it is not necessary t
|
||||
</overview>
|
||||
<recommendation>
|
||||
<p>
|
||||
Add comments to document the purpose of the function. In particular, ensure that the public API of the function is carefully documented. This reduces the chance that a future change to the function will introduce a defect by changing the API and breaking the expections of the calling functions.
|
||||
Add comments to document the purpose of the function. In particular, ensure that the public API of the function is carefully documented. This reduces the chance that a future change to the function will introduce a defect by changing the API and breaking the expectations of the calling functions.
|
||||
</p>
|
||||
|
||||
</recommendation>
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
<overview>
|
||||
<p>
|
||||
This rule finds comparison expressions that use 2 or more comparison operators and are not completely paranthesized.
|
||||
This rule finds comparison expressions that use 2 or more comparison operators and are not completely parenthesized.
|
||||
It is best to fully parenthesize complex comparison expressions to explicitly define the order of the comparison operators.
|
||||
</p>
|
||||
|
||||
|
||||
@@ -6,9 +6,9 @@
|
||||
<overview>
|
||||
<p>This rule finds logical-not operator usage as an operator for in a bit-wise operation.</p>
|
||||
|
||||
<p>Due to the nature of logical operation result value, only the lowest bit could possibly be set, and it is unlikely to be intent in bitwise opeartions. Violations are often indicative of a typo, using a logical-not (<code>!</code>) opeartor instead of the bit-wise not (<code>~</code>) operator. </p>
|
||||
<p>Due to the nature of logical operation result value, only the lowest bit could possibly be set, and it is unlikely to be intent in bitwise operations. Violations are often indicative of a typo, using a logical-not (<code>!</code>) operator instead of the bit-wise not (<code>~</code>) operator. </p>
|
||||
<p>This rule is restricted to analyze bit-wise and (<code>&</code>) and bit-wise or (<code>|</code>) operation in order to provide better precision.</p>
|
||||
<p>This rule ignores instances where a double negation (<code>!!</code>) is explicitly used as the opeartor of the bitwise operation, as this is a commonly used as a mechanism to normalize an integer value to either 1 or 0.</p>
|
||||
<p>This rule ignores instances where a double negation (<code>!!</code>) is explicitly used as the operator of the bitwise operation, as this is a commonly used as a mechanism to normalize an integer value to either 1 or 0.</p>
|
||||
<p>NOTE: It is not recommended to use this rule in kernel code or older C code as it will likely find several false positive instances.</p>
|
||||
|
||||
</overview>
|
||||
|
||||
@@ -49,7 +49,7 @@ pointer overflow.
|
||||
|
||||
<p>
|
||||
While it's not the subject of this query, the expression <code>ptr + i <
|
||||
ptr_end</code> is also an invalid range check. It's undefined behavor in
|
||||
ptr_end</code> is also an invalid range check. It's undefined behavior in
|
||||
C/C++ to create a pointer that points more than one past the end of an
|
||||
allocation.
|
||||
</p>
|
||||
|
||||
@@ -12,7 +12,7 @@ the third argument to the entire size of the destination buffer.
|
||||
Executing a call of this type may cause a buffer overflow unless the buffer is known to be empty.</p>
|
||||
|
||||
<p>Similarly, calls of the form <code>strncat(dest, src, sizeof (dest) - strlen (dest))</code> allow one
|
||||
byte to be written ouside the <code>dest</code> buffer.</p>
|
||||
byte to be written outside the <code>dest</code> buffer.</p>
|
||||
|
||||
<p>Buffer overflows can lead to anything from a segmentation fault to a security vulnerability.</p>
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
<p>
|
||||
This metric provides an indication of the lack of cohesion of a class,
|
||||
using a method proposed by Chidamber and Kemerer in 1994. The idea
|
||||
behind measuring a class's cohesion is that most funcions in well-designed
|
||||
behind measuring a class's cohesion is that most functions in well-designed
|
||||
classes will access the same fields. Types that exhibit a lack of cohesion
|
||||
are often trying to take on multiple responsibilities, and should be split
|
||||
into several smaller classes.
|
||||
|
||||
@@ -11,7 +11,7 @@
|
||||
by changes to other packages. If this metric value is high, a package is easily
|
||||
influenced. If the values is low, the impact of changes to other packages is likely to be minimal. Instability
|
||||
is estimated as the number of outgoing dependencies relative to the total
|
||||
number of depencies.</p>
|
||||
number of dependencies.</p>
|
||||
</overview>
|
||||
|
||||
<references>
|
||||
|
||||
@@ -11,7 +11,7 @@
|
||||
by changes to other packages. If this metric value is high, a package is easily
|
||||
influenced. If the values is low, the impact of changes to other packages is likely to be minimal. Instability
|
||||
is estimated as the number of outgoing dependencies relative to the total
|
||||
number of depencies.</p>
|
||||
number of dependencies.</p>
|
||||
</overview>
|
||||
|
||||
<references>
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
|
||||
<overview>
|
||||
<p>This query indicates that a call is setting the DACL field in a <code>SECURITY_DESCRIPTOR</code> to null.</p>
|
||||
<p>When using <code>SetSecurityDescriptorDacl</code> to set a discretionary access control (DACL), setting the <code>bDaclPresent</code> argument to <code>TRUE</code> indicates the prescence of a DACL in the security description in the argument <code>pDacl</code>.</p>
|
||||
<p>When using <code>SetSecurityDescriptorDacl</code> to set a discretionary access control (DACL), setting the <code>bDaclPresent</code> argument to <code>TRUE</code> indicates the presence of a DACL in the security description in the argument <code>pDacl</code>.</p>
|
||||
<p>When the <code>pDacl</code> parameter does not point to a DACL (i.e. it is <code>NULL</code>) and the <code>bDaclPresent</code> flag is <code>TRUE</code>, a <code>NULL DACL</code> is specified.</p>
|
||||
<p>A <code>NULL DACL</code> grants full access to any user who requests it; normal security checking is not performed with respect to the object.</p>
|
||||
</overview>
|
||||
|
||||
@@ -12,7 +12,7 @@ The user should check the return value of `scanf` and related functions and chec
|
||||
</p>
|
||||
</recommendation>
|
||||
<example>
|
||||
<p>The first first example below is correct, as value of `i` is only read once it is checked that `scanf` has read one item. The second example is incorrect, as the return value of `scanf` is not checked, and as `scanf` might have failed to read any item before returning.</p>
|
||||
<p>The first example below is correct, as value of `i` is only read once it is checked that `scanf` has read one item. The second example is incorrect, as the return value of `scanf` is not checked, and as `scanf` might have failed to read any item before returning.</p>
|
||||
<sample src="ImproperCheckReturnValueScanf.cpp" />
|
||||
|
||||
</example>
|
||||
|
||||
@@ -5,12 +5,12 @@
|
||||
<overview>
|
||||
<p>
|
||||
Some header files, such as those which define structures or classes, cannot be included more than once within a translation unit, as doing so would
|
||||
cause a redefinition error. Such headers must be guarded to prevent ill-effects from multiple inclusion. Simlarly, if header files include other
|
||||
cause a redefinition error. Such headers must be guarded to prevent ill-effects from multiple inclusion. Similarly, if header files include other
|
||||
header files, and this inclusion graph contains a cycle, then at least one file within the cycle must contain header guards in order to break the
|
||||
cycle. Because of cases like these, all headers should be guarded as a matter of good practice, even if they do not strictly need to be.
|
||||
</p>
|
||||
<p>
|
||||
Furthermore, most modern compilers contain optimisations which are triggered by header guards. If the header guard strictly conforms to the pattern
|
||||
Furthermore, most modern compilers contain optimizations which are triggered by header guards. If the header guard strictly conforms to the pattern
|
||||
that compilers expect, then inclusions of that header other than the first have absolutely no effect: the file isn't re-read from disk, nor is it
|
||||
re-tokenised or re-preprocessed. This can result in a noticeable, albeit minor, improvement to compilation time.
|
||||
</p>
|
||||
|
||||
Reference in New Issue
Block a user