Merge pull request #10743 from jsoref/spelling

Spelling
This commit is contained in:
Jeroen Ketema
2022-10-12 12:48:22 +02:00
committed by GitHub
57 changed files with 68 additions and 68 deletions

View File

@@ -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>

View File

@@ -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>

View File

@@ -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>

View File

@@ -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>

View File

@@ -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>&amp;</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>

View File

@@ -49,7 +49,7 @@ pointer overflow.
<p>
While it's not the subject of this query, the expression <code>ptr + i &lt;
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>

View File

@@ -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>

View File

@@ -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.

View File

@@ -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>

View File

@@ -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>

View File

@@ -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>

View File

@@ -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>

View File

@@ -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>