None
-Evaluation of an expression may produce side effects. At specific points during execution, known as sequence points, all side effects of previous evaluations are complete, and no side effects of subsequent evaluations have yet taken place. Do not depend on the order of evaluation for side effects unless there is an intervening sequence point.
+The C Standard, 6.5, paragraph 2 [ISO/IEC 9899:2011], states
+++If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. If there are multiple allowable orderings of the subexpressions of an expression, the behavior is undefined if such an unsequenced side effect occurs in any of the orderings.
+
This requirement must be met for each allowable ordering of the subexpressions of a full expression; otherwise, the behavior is undefined. (See undefined behavior 35.)
+The following sequence points are defined in the C Standard, Annex C [ISO/IEC 9899:2011]:
+&&Logical OR: ||Comma: ,?: operator and whichever of the second and third operands is evaluatedif or switch)The controlling expression of a while or do statementEach of the (optional) expressions of a for statementThe (optional) expression in a return statementFurthermore, Section 6.5.16, paragraph 3 says (regarding assignment operations):
+++The side effect of updating the stored value of the left operand is sequenced after the value computations of the left and right operands.
+
This rule means that statements such as
+have defined behavior, and statements such as the following do not:
+- ... -
+/* i is read other than to determine the value to be stored */ +a[i++] = i; +Not all instances of a comma in C code denote a usage of the comma operator. For example, the comma between arguments in a function call is not a sequence point. However, according to the C Standard, 6.5.2.2, paragraph 10 [ISO/IEC 9899:2011]
+++Every evaluation in the calling function (including other function calls) that is not otherwise specifically sequenced before or after the execution of the body of the called function is indeterminately sequenced with respect to the execution of the called function.
+
This rule means that the order of evaluation for function call arguments is unspecified and can happen in any order.
+Programs cannot safely rely on the order of evaluation of operands between sequence points. In this noncompliant code example, i is evaluated twice without an intervening sequence point, so the behavior of the expression is undefined:
These examples are independent of the order of evaluation of the operands and can be interpreted in only one way:
+- ... -
-Alternatively:
+The call to func() in this noncompliant code example has undefined behavior because there is no sequence point between the argument expressions:
The first (left) argument expression reads the value of i (to determine the value to be stored) and then modifies i. The second (right) argument expression reads the value of i between the same pair of sequence points as the first argument, but not to determine the value to be stored in i. This additional attempt to read the value of i has undefined behavior.
This compliant solution is appropriate when the programmer intends for both arguments to func() to be equivalent:
This compliant solution is appropriate when the programmer intends for the second argument to be 1 greater than the first:
+The order of evaluation for function arguments is unspecified. This noncompliant code example exhibits unspecified behavior but not undefined behavior:
+It is unspecified what order a() and b() are called in; the only guarantee is that both a() and b() will be called before c() is called. If a() or b() rely on shared state when calculating their return value, as they do in this example, the resulting arguments passed to c() may differ between compilers or architectures.
In this compliant solution, the order of evaluation for a() and b() is fixed, and so no unspecified behavior occurs:
Attempting to modify an object multiple times between sequence points may cause that object to take on an unexpected value, which can lead to unexpected program behavior.
+| + Rule + | ++ Severity + | ++ Likelihood + | ++ Remediation Cost + | ++ Priority + | ++ Level + | +
|---|---|---|---|---|---|
| + EXP30-C + | ++ Medium + | ++ Probable + | ++ Medium + | ++ P8 + | ++ L2 + | +
| + Tool + | ++ Version + | ++ Checker + | ++ Description + | +
|---|---|---|---|
| + + Astrée + + | ++ 20.10 + | ++ evaluation-order + multiple-volatile-accesses + | ++ Fully checked + | +
| + + Axivion Bauhaus Suite + + | ++ 7.2.0 + | ++ CertC-EXP30 + | ++ | +
| + + Clang + + | ++ 3.9 + | +
+ -Wunsequenced
+ |
+ + Detects simple violations of this rule, but does not diagnose unsequenced function call arguments. + | +
| + + Compass/ROSE + + | ++ | ++ | ++ Can detect simple violations of this rule. It needs to examine each expression and make sure that no variable is modified twice in the expression. It also must check that no variable is modified once, then read elsewhere, with the single exception that a variable may appear on both the left and right of an assignment operator + | +
| + + Coverity + + | ++ 2017.07 + | ++ EVALUATION_ORDER + | ++ Can detect the specific instance where a statement contains multiple side effects on the same value with an undefined evaluation order because, with different compiler flags or different compilers or platforms, the statement may behave differently + | +
| + + ECLAIR + + | ++ 1.2 + | ++ CC2.EXP30 + | ++ Fully implemented + | +
| + + GCC + + | ++ 4.3.5 + | ++ | +
+ Can detect violations of this rule when the
+ -Wsequence-point
+ flag is used
+ |
+
| + + Helix QAC + + | ++ 2022.1 + | ++ C0400, C0401, C0402, C0403, C0404, C0405 + | ++ | +
| + + Klocwork + + | ++ 2022.1 + | ++ PORTING.VAR.EFFECTS + MISRA.INCR_DECR.OTHER + | ++ | +
| + + LDRA tool suite + + | ++ 9.7.1 + | ++ 35 D, 1 Q, 9 S, 30 S, 134 S + | ++ Partially implemented + | +
| + + Parasoft C/C++test + + | ++ 2021.2 + | ++ CERT_C-EXP30-a + CERT_C-EXP30-b + CERT_C-EXP30-c + CERT_C-EXP30-d + | ++ The value of an expression shall be the same under any order of evaluation that the standard permits + Don't write code that depends on the order of evaluation of function arguments + Don't write code that depends on the order of evaluation of function designator and function arguments + Don't write code that depends on the order of evaluation of expression that involves a function call + | +
| + + PC-lint Plus + + | ++ 1.4 + | ++ 564 + | ++ Partially supported + | +
| + + Polyspace Bug Finder + + | ++ R2021a + | ++ + CERT C: Rule EXP30-C + + | ++ Checks for situations when expression value depends on order of evaluation or of side effects (rule partially covered) + | +
| + + PRQA QA-C + + | ++ 9.7 + | ++ 0400, 0401, 0402, + 0403, 0404, 0405 + | ++ Fully implemented + | +
| + + PVS-Studio + + | ++ 7.18 + | ++ V532 + + , + + V567 + | ++ | +
| + + RuleChecker + + | ++ 20.10 + | ++ evaluation-order + multiple-volatile-accesses + | ++ Fully checked + | +
| + + Splint + + | ++ 3.1.1 + | ++ | ++ | +
| + + SonarQube C/C++ Plugin + + | ++ 3.11 + | ++ IncAndDecMixedWithOtherOperators + | ++ | +
| + + TrustInSoft Analyzer + + | ++ 1.38 + | ++ separated + | ++ Exhaustively verified (see + + one compliant and one non-compliant example + + ). + | +
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
+Key here (explains table format and definitions)
+| + Taxonomy + | ++ Taxonomy item + | ++ Relationship + | +
|---|---|---|
| + + CERT C + + | ++ + EXP50-CPP. Do not depend on the order of evaluation for side effects + + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
| + + CERT Oracle Secure Coding Standard for Java + + | ++ + EXP05-J. Do not follow a write by a subsequent write or read of the same object within an expression + + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
| + + ISO/IEC TR 24772:2013 + + | ++ Operator Precedence/Order of Evaluation [JCW] + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
| + + ISO/IEC TR 24772:2013 + + | ++ Side-effects and Order of Evaluation [SAM] + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
| + + MISRA C:2012 + + | ++ Rule 13.2 (required) + | ++ CERT cross-reference in + + MISRA C:2012 – Addendum 3 + + | +
| + + CWE 2.11 + + | ++ + CWE-758 + + | ++ 2017-07-07: CERT: Rule subset of CWE + | +
Key here for mapping notes
+CWE-758 and EXP30-C
+Independent( INT34-C, INT36-C, MEM30-C, MSC37-C, FLP32-C, EXP33-C, EXP30-C, ERR34-C, ARR32-C)
+CWE-758 = Union( EXP30-C, list) where list =
+| + [ + + ISO/IEC 9899:2011 + + ] + | ++ 6.5, "Expressions" + 6.5.2.2, "Function Calls" + Annex C, "Sequence Points" + | +
| + [ + + Saks 2007 + + ] + | ++ | +
| + [ + + Summit 2005 + + ] + | ++ Questions 3.1, 3.2, 3.3, 3.3b, 3.7, 3.8, 3.9, 3.10a, 3.10b, and 3.11 + | +
None
-Evaluation of an expression may produce side effects. At specific points during execution, known as sequence points, all side effects of previous evaluations are complete, and no side effects of subsequent evaluations have yet taken place. Do not depend on the order of evaluation for side effects unless there is an intervening sequence point.
+The C Standard, 6.5, paragraph 2 [ISO/IEC 9899:2011], states
+++If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. If there are multiple allowable orderings of the subexpressions of an expression, the behavior is undefined if such an unsequenced side effect occurs in any of the orderings.
+
This requirement must be met for each allowable ordering of the subexpressions of a full expression; otherwise, the behavior is undefined. (See undefined behavior 35.)
+The following sequence points are defined in the C Standard, Annex C [ISO/IEC 9899:2011]:
+&&Logical OR: ||Comma: ,?: operator and whichever of the second and third operands is evaluatedif or switch)The controlling expression of a while or do statementEach of the (optional) expressions of a for statementThe (optional) expression in a return statementFurthermore, Section 6.5.16, paragraph 3 says (regarding assignment operations):
+++The side effect of updating the stored value of the left operand is sequenced after the value computations of the left and right operands.
+
This rule means that statements such as
+have defined behavior, and statements such as the following do not:
+- ... -
+/* i is read other than to determine the value to be stored */ +a[i++] = i; +Not all instances of a comma in C code denote a usage of the comma operator. For example, the comma between arguments in a function call is not a sequence point. However, according to the C Standard, 6.5.2.2, paragraph 10 [ISO/IEC 9899:2011]
+++Every evaluation in the calling function (including other function calls) that is not otherwise specifically sequenced before or after the execution of the body of the called function is indeterminately sequenced with respect to the execution of the called function.
+
This rule means that the order of evaluation for function call arguments is unspecified and can happen in any order.
+Programs cannot safely rely on the order of evaluation of operands between sequence points. In this noncompliant code example, i is evaluated twice without an intervening sequence point, so the behavior of the expression is undefined:
These examples are independent of the order of evaluation of the operands and can be interpreted in only one way:
+- ... -
-Alternatively:
+The call to func() in this noncompliant code example has undefined behavior because there is no sequence point between the argument expressions:
The first (left) argument expression reads the value of i (to determine the value to be stored) and then modifies i. The second (right) argument expression reads the value of i between the same pair of sequence points as the first argument, but not to determine the value to be stored in i. This additional attempt to read the value of i has undefined behavior.
This compliant solution is appropriate when the programmer intends for both arguments to func() to be equivalent:
This compliant solution is appropriate when the programmer intends for the second argument to be 1 greater than the first:
+The order of evaluation for function arguments is unspecified. This noncompliant code example exhibits unspecified behavior but not undefined behavior:
+It is unspecified what order a() and b() are called in; the only guarantee is that both a() and b() will be called before c() is called. If a() or b() rely on shared state when calculating their return value, as they do in this example, the resulting arguments passed to c() may differ between compilers or architectures.
In this compliant solution, the order of evaluation for a() and b() is fixed, and so no unspecified behavior occurs:
Attempting to modify an object multiple times between sequence points may cause that object to take on an unexpected value, which can lead to unexpected program behavior.
+| + Rule + | ++ Severity + | ++ Likelihood + | ++ Remediation Cost + | ++ Priority + | ++ Level + | +
|---|---|---|---|---|---|
| + EXP30-C + | ++ Medium + | ++ Probable + | ++ Medium + | ++ P8 + | ++ L2 + | +
| + Tool + | ++ Version + | ++ Checker + | ++ Description + | +
|---|---|---|---|
| + + Astrée + + | ++ 20.10 + | ++ evaluation-order + multiple-volatile-accesses + | ++ Fully checked + | +
| + + Axivion Bauhaus Suite + + | ++ 7.2.0 + | ++ CertC-EXP30 + | ++ | +
| + + Clang + + | ++ 3.9 + | +
+ -Wunsequenced
+ |
+ + Detects simple violations of this rule, but does not diagnose unsequenced function call arguments. + | +
| + + Compass/ROSE + + | ++ | ++ | ++ Can detect simple violations of this rule. It needs to examine each expression and make sure that no variable is modified twice in the expression. It also must check that no variable is modified once, then read elsewhere, with the single exception that a variable may appear on both the left and right of an assignment operator + | +
| + + Coverity + + | ++ 2017.07 + | ++ EVALUATION_ORDER + | ++ Can detect the specific instance where a statement contains multiple side effects on the same value with an undefined evaluation order because, with different compiler flags or different compilers or platforms, the statement may behave differently + | +
| + + ECLAIR + + | ++ 1.2 + | ++ CC2.EXP30 + | ++ Fully implemented + | +
| + + GCC + + | ++ 4.3.5 + | ++ | +
+ Can detect violations of this rule when the
+ -Wsequence-point
+ flag is used
+ |
+
| + + Helix QAC + + | ++ 2022.1 + | ++ C0400, C0401, C0402, C0403, C0404, C0405 + | ++ | +
| + + Klocwork + + | ++ 2022.1 + | ++ PORTING.VAR.EFFECTS + MISRA.INCR_DECR.OTHER + | ++ | +
| + + LDRA tool suite + + | ++ 9.7.1 + | ++ 35 D, 1 Q, 9 S, 30 S, 134 S + | ++ Partially implemented + | +
| + + Parasoft C/C++test + + | ++ 2021.2 + | ++ CERT_C-EXP30-a + CERT_C-EXP30-b + CERT_C-EXP30-c + CERT_C-EXP30-d + | ++ The value of an expression shall be the same under any order of evaluation that the standard permits + Don't write code that depends on the order of evaluation of function arguments + Don't write code that depends on the order of evaluation of function designator and function arguments + Don't write code that depends on the order of evaluation of expression that involves a function call + | +
| + + PC-lint Plus + + | ++ 1.4 + | ++ 564 + | ++ Partially supported + | +
| + + Polyspace Bug Finder + + | ++ R2021a + | ++ + CERT C: Rule EXP30-C + + | ++ Checks for situations when expression value depends on order of evaluation or of side effects (rule partially covered) + | +
| + + PRQA QA-C + + | ++ 9.7 + | ++ 0400, 0401, 0402, + 0403, 0404, 0405 + | ++ Fully implemented + | +
| + + PVS-Studio + + | ++ 7.18 + | ++ V532 + + , + + V567 + | ++ | +
| + + RuleChecker + + | ++ 20.10 + | ++ evaluation-order + multiple-volatile-accesses + | ++ Fully checked + | +
| + + Splint + + | ++ 3.1.1 + | ++ | ++ | +
| + + SonarQube C/C++ Plugin + + | ++ 3.11 + | ++ IncAndDecMixedWithOtherOperators + | ++ | +
| + + TrustInSoft Analyzer + + | ++ 1.38 + | ++ separated + | ++ Exhaustively verified (see + + one compliant and one non-compliant example + + ). + | +
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
+Key here (explains table format and definitions)
+| + Taxonomy + | ++ Taxonomy item + | ++ Relationship + | +
|---|---|---|
| + + CERT C + + | ++ + EXP50-CPP. Do not depend on the order of evaluation for side effects + + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
| + + CERT Oracle Secure Coding Standard for Java + + | ++ + EXP05-J. Do not follow a write by a subsequent write or read of the same object within an expression + + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
| + + ISO/IEC TR 24772:2013 + + | ++ Operator Precedence/Order of Evaluation [JCW] + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
| + + ISO/IEC TR 24772:2013 + + | ++ Side-effects and Order of Evaluation [SAM] + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
| + + MISRA C:2012 + + | ++ Rule 13.2 (required) + | ++ CERT cross-reference in + + MISRA C:2012 – Addendum 3 + + | +
| + + CWE 2.11 + + | ++ + CWE-758 + + | ++ 2017-07-07: CERT: Rule subset of CWE + | +
Key here for mapping notes
+CWE-758 and EXP30-C
+Independent( INT34-C, INT36-C, MEM30-C, MSC37-C, FLP32-C, EXP33-C, EXP30-C, ERR34-C, ARR32-C)
+CWE-758 = Union( EXP30-C, list) where list =
+| + [ + + ISO/IEC 9899:2011 + + ] + | ++ 6.5, "Expressions" + 6.5.2.2, "Function Calls" + Annex C, "Sequence Points" + | +
| + [ + + Saks 2007 + + ] + | ++ | +
| + [ + + Summit 2005 + + ] + | ++ Questions 3.1, 3.2, 3.3, 3.3b, 3.7, 3.8, 3.9, 3.10a, 3.10b, and 3.11 + | +
None
-Some operators do not evaluate their operands beyond the type information the operands provide. When using one of these operators, do not pass an operand that would otherwise yield a side effect since the side effect will not be generated.
+The sizeof operator yields the size (in bytes) of its operand, which may be an expression or the parenthesized name of a type. In most cases, the operand is not evaluated. A possible exception is when the type of the operand is a variable length array type (VLA); then the expression is evaluated. When part of the operand of the sizeof operator is a VLA type and when changing the value of the VLA's size expression would not affect the result of the operator, it is unspecified whether or not the size expression is evaluated. (See unspecified behavior 22.)
The operand passed to_Alignof is never evaluated, despite not being an expression. For instance, if the operand is a VLA type and the VLA's size expression contains a side effect, that side effect is never evaluated.
The operand used in the controlling expression of a _Generic selection expression is never evaluated.
Providing an expression that appears to produce side effects may be misleading to programmers who are not aware that these expressions are not evaluated, and in the case of a VLA used in sizeof, have unspecified results. As a result, programmers may make invalid assumptions about program state, leading to errors and possible software vulnerabilities.
This rule is similar to PRE31-C. Avoid side effects in arguments to unsafe macros.
+In this noncompliant code example, the expression a++ is not evaluated:
Consequently, the value of a after b has been initialized is 14.
In this compliant solution, the variable a is incremented outside of the sizeof operation:
In this noncompliant code example, the expression ++n in the initialization expression of a must be evaluated because its value affects the size of the VLA operand of the sizeof operator. However, in the initialization expression of b, the expression ++n % 1 evaluates to 0. This means that the value of n does not affect the result of the sizeof operator. Consequently, it is unspecified whether or not n will be incremented when initializing b.
- ... -
+ printf("%zu, %zu, %zu\n", a, b, n); + /* ... */ +}This compliant solution avoids changing the value of the variable n used in each sizeof expression and instead increments n safely afterwards:
This noncompliant code example attempts to modify a variable's value as part of the _Generic selection control expression. The programmer may expect that a is incremented, but because _Generic does not evaluate its control expression, the value of a is not modified.
- ... -
-In this compliant solution, a is incremented outside of the _Generic selection expression:
This noncompliant code example attempts to modify a variable while getting its default alignment value. The user may have expected val to be incremented as part of the _Alignof expression, but because _Alignof does not evaluate its operand, val is unchanged.
This compliant solution moves the expression out of the _Alignof operator:
EXP44-C-EX1: Reading a volatile-qualified value is a side-effecting operation. However, accessing a value through a volatile-qualified type does not guarantee side effects will happen on the read of the value unless the underlying object is also volatile-qualified. Idiomatic reads of a volatile-qualified object are permissible as an operand to a sizeof(), _Alignof(), or _Generic expression, as in the following example:
If expressions that appear to produce side effects are supplied to an operator that does not evaluate its operands, the results may be different than expected. Depending on how this result is used, it can lead to unintended program behavior.
+| + Rule + | ++ Severity + | ++ Likelihood + | ++ Remediation Cost + | ++ Priority + | ++ Level + | +
|---|---|---|---|---|---|
| + EXP44-C + | ++ Low + | ++ Unlikely + | ++ Low + | ++ P3 + | ++ L3 + | +
| + Tool + | ++ Version + | ++ Checker + | ++ Description + | +
|---|---|---|---|
| + + Astrée + + | ++ 20.10 + | ++ alignof-side-effectgeneric-selection-side-effectsizeof + | ++ Fully checked + | +
| + + Axivion Bauhaus Suite + + | ++ 7.2.0 + | ++ CertC-EXP44 + | ++ | +
| + + Clang + + | ++ 3.9 + | +
+ -Wunevaluated-expression
+ |
+
+ Can diagnose some instance of this rule, but not all (such as the
+ _Alignof
+ NCCE).
+ |
+
| + + CodeSonar + + | ++ 6.2p0 + | ++ LANG.STRUCT.SE.SIZEOF + | ++ Side effects in sizeof + | +
| + + Compass/ROSE + + | ++ | ++ | ++ | +
| + + Coverity + + | ++ 2017.07 + | ++ MISRA C 2004 Rule 12.3 + | ++ Partially implemented + | +
| + + ECLAIR + + | ++ 1.2 + | ++ CC2.EXP06 + | ++ Fully implemented + | +
| + + Helix QAC + + | ++ 2022.1 + | ++ C3307 + | ++ | +
| + + Klocwork + + | ++ 2022.1 + | ++ MISRA.SIZEOF.SIDE_EFFECT + | ++ | +
| + + LDRA tool suite + + | ++ 9.7.1 + | ++ 54 S, 653 S + | ++ Fully implemented + | +
| + + Parasoft C/C++test + + | ++ 2021.2 + | ++ CERT_C-EXP44-a + CERT_C-EXP44-b + | ++ Object designated by a volatile lvalue should not be accessed in the operand of the sizeof operator + The function call that causes the side effect shall not be the operand of the sizeof operator + | +
| + + PC-lint Plus + + | ++ 1.4 + | ++ 9006 + | ++ Partially supported: reports use of sizeof with an expression that would have side effects + | +
| + + Polyspace Bug Finder + + | ++ R2021a + | ++ + CERT C: Rule EXP44-C + + | ++ Checks for situations when side effects of specified expressions are ignored (rule fully covered) + | +
| + + PRQA QA-C + + | ++ 9.7 + | ++ 3307 + | ++ Fully implemented + | +
| + + PVS-Studio + + | ++ 7.18 + | ++ V568 + | ++ | +
| + + RuleChecker + + | ++ 20.10 + | ++ alignof-side-effectgeneric-selection-side-effectsizeof + | ++ Fully checked + | +
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
+Key here (explains table format and definitions)
+| + Taxonomy + | ++ Taxonomy item + | ++ Relationship + | +
|---|---|---|
| + + CERT C + + | ++ + EXP52-CPP. Do not rely on side effects in unevaluated operands + + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
None
-- ... -
- -- ... -
-Do not use the assignment operator in the contexts listed in the following table because doing so typically indicates programmer error and can result in unexpected behavior.
+| + Operator + | ++ Context + | +
|---|---|
+ if
+ |
+ + Controlling expression + | +
+ while
+ |
+ + Controlling expression + | +
+ do ... while
+ |
+ + Controlling expression + | +
+ for
+ |
+ + Second operand + | +
+ ?:
+ |
+ + First operand + | +
+ ?:
+ |
+ + Second or third operands, where the ternary expression is used in any of these contexts + | +
+ &&
+ |
+ + Either operand + | +
+ ||
+ |
+ + either operand + | +
+ ,
+ |
+ + Second operand, when the comma expression is used in any of these contexts + | +
Performing assignment statements in other contexts do not violate this rule. However, they may violate other rules, such as EXP30-C. Do not depend on the order of evaluation for side effects.
+Noncompliant Code Example
+In this noncompliant code example, an assignment expression is the outermost expression in an if statement:
Although the intent of the code may be to assign b to a and test the value of the result for equality to 0, it is frequently a case of the programmer mistakenly using the assignment operator = instead of the equals operator ==. Consequently, many compilers will warn about this condition, making this coding error detectable by adhering to MSC00-C. Compile cleanly at high warning levels.
When the assignment of b to a is not intended, the conditional block is now executed when a is equal to b:
When the assignment is intended, this compliant solution explicitly uses inequality as the outermost expression while performing the assignment in the inner expression:
+It is less desirable in general, depending on what was intended, because it mixes the assignment in the condition, but it is clear that the programmer intended the assignment to occur.
+In this noncompliant code example, the expression x = y is used as the controlling expression of the while statement:
When the assignment of y to x is not intended, the conditional block should be executed only when x is equal to y, as in this compliant solution:
+When the assignment is intended, this compliant solution can be used:
+The same result can be obtained using the for statement, which is specifically designed to evaluate an expression on each iteration of the loop, just before performing the test in its controlling expression. Remember that its controlling expression is the second operand, where the assignment occurs in its third operand:
In this noncompliant example, the expression p = q is used as the controlling expression of the while statement:
In this compliant solution, the expression x = y is not used as the controlling expression of the while statement:
This noncompliant code example has a typo that results in an assignment rather than a comparison.
+Many compilers will warn about this condition. This coding error would typically be eliminated by adherence to MSC00-C. Compile cleanly at high warning levels. Although this code compiles, it will cause unexpected behavior to an unsuspecting programmer. If the intent was to verify a string such as a password, user name, or group user ID, the code may produce significant vulnerabilities and require significant debugging.
+When comparisons are made between a variable and a literal or const-qualified variable, placing the variable on the right of the comparison operation can prevent a spurious assignment.
+In this code example, the literals are placed on the left-hand side of each comparison. If the programmer were to inadvertently use an assignment operator, the statement would assign ch to '\t', which is invalid and produces a diagnostic message.
Due to the diagnostic, the typo will be easily spotted and fixed.
+As a result, any mistaken use of the assignment operator that could otherwise create a vulnerability for operations such as string verification will result in a compiler diagnostic regardless of compiler, warning level, or implementation.
+EXP45-C-EX1: Assignment can be used where the result of the assignment is itself an operand to a comparison expression or relational expression. In this compliant example, the expression x = y is itself an operand to a comparison operation:
EXP45-C-EX2: Assignment can be used where the expression consists of a single primary expression. The following code is compliant because the expression x = y is a single primary expression:
The following controlling expression is noncompliant because && is not a comparison or relational operator and the entire expression is not primary:
When the assignment of v to w is not intended, the following controlling expression can be used to execute the conditional block when v is equal to w:
When the assignment is intended, the following controlling expression can be used:
+EXP45-C-EX3: Assignment can be used in a function argument or array index. In this compliant solution, the expression x = y is used in a function argument:
Errors of omission can result in unintended program flow.
+| + Recommendation + | ++ Severity + | ++ Likelihood + | ++ Remediation Cost + | ++ Priority + | ++ Level + | +
|---|---|---|---|---|---|
| + EXP45-C + | ++ Low + | ++ Likely + | ++ Medium + | ++ P6 + | ++ L2 + | +
| + Tool + | ++ Version + | ++ Checker + | ++ Description + | +
|---|---|---|---|
| + + Astrée + + | ++ 20.10 + | ++ assignment-conditional + | ++ Fully checked + | +
| + + Axivion Bauhaus Suite + + | ++ 7.2.0 + | ++ CertC-EXP45 + | ++ | +
| + + Clang + + | ++ 3.9 + | +
+ -Wparentheses
+ |
+ + Can detect some instances of this rule, but does not detect all + | +
| + + CodeSonar + + | ++ 6.2p0 + | ++ LANG.STRUCT.CONDASSIGLANG.STRUCT.SE.CONDLANG.STRUCT.USEASSIGN + | ++ Assignment in conditional + Condition contains side effects + Assignment result in expression + | +
| + + Compass/ROSE + + | ++ | ++ | +
+ Could detect violations of this recommendation by identifying any assignment expression as the top-level expression in an
+ if
+ or
+ while
+ statement
+ |
+
| + + ECLAIR + + | ++ 1.2 + | ++ CC2.EXP18 + CC2.EXP21 + | ++ Fully implemented + | +
| + + GCC + + | ++ 4.3.5 + | ++ | +
+ Can detect violations of this recommendation when the
+ -Wall
+ flag is used
+ |
+
| + + Helix QAC + + | ++ 2022.1 + | ++ C3314, C3326, C3344, C3416 + C++4071, C++4074 + | ++ | +
| + + Klocwork + + | ++ 2022.1 + | ++ ASSIGCOND.CALL + ASSIGCOND.GENMISRA.ASSIGN.COND + | ++ | +
| + + LDRA tool suite + + | ++ 9.7.1 + | ++ 114 S, 132 S + | ++ Enhanced Enforcement + | +
| + + Parasoft C/C++test + + | ++ 2021.2 + | ++ CERT_C-EXP45-b + CERT_C-EXP45-d + | ++ Assignment operators shall not be used in conditions without brackets + Assignment operators shall not be used in expressions that yield a Boolean value + | +
| + + PC-lint Plus + + | ++ 1.4 + | ++ 720 + | ++ Partially supported: reports Boolean test of unparenthesized assignment + | +
| + + Polyspace Bug Finder + + | ++ R2021a + | ++ + CERT C: Rule EXP45-C + + | ++ Checks for invalid use of = (assignment) operator (rule fully covered) + | +
| + + PRQA QA-C + + | ++ 9.7 + | ++ 3314, 3326, 3344, 3416 + | ++ Partially implemented + | +
| + + PRQA QA-C++ + + | ++ 4.4 + | ++ 4071, 4074 + | ++ | +
| + + PVS-Studio + + | ++ 7.18 + | ++ V559 + , + V633 + , + V699 + | ++ | +
| + + RuleChecker + + | ++ 20.10 + | ++ assignment-conditional + | ++ Fully checked + | +
| + + SonarQube C/C++ Plugin + + | ++ 3.11 + | ++ AssignmentInSubExpression + | ++ | +
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
+Key here (explains table format and definitions)
+| + Taxonomy + | ++ Taxonomy item + | ++ Relationship + | +
|---|---|---|
| + + CERT C + + | ++ + EXP19-CPP. Do not perform assignments in conditional expressions + + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
| + + CERT Oracle Secure Coding Standard for Java + + | ++ + EXP51-J. Do not perform assignments in conditional expressions + + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
| + + ISO/IEC TR 24772:2013 + + | ++ Likely Incorrect Expression [KOA] + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
| + + ISO/IEC TS 17961 + + | ++ No assignment in conditional expressions [boolasgn] + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
| + + CWE 2.11 + + | ++ + CWE-480 + + , Use of Incorrect Operator + | ++ 2017-07-05: CERT: Rule subset of CWE + | +
| + + CWE 2.11 + + | ++ + CWE-481 + + | ++ 2017-07-05: CERT: Rule subset of CWE + | +
Key here for mapping notes
+CWE-480 and EXP45-C
+Intersection( EXP45-C, EXP46-C) = Ø
+CWE-480 = Union( EXP45-C, list) where list =
+CWE-569 and EXP45-C
+CWE-480 = Subset( CWE-569)
+| + [ + + Dutta 03 + + ] + | ++ "Best Practices for Programming in C" + | +
| + [ + + Hatton 1995 + + ] + | ++ Section 2.7.2, "Errors of Omission and Addition" + | +
None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-Pseudorandom number generators use mathematical algorithms to produce a sequence of numbers with good statistical properties, but the numbers produced are not genuinely random.
+The C Standard rand() function makes no guarantees as to the quality of the random sequence produced. The numbers generated by some implementations of rand() have a comparatively short cycle and the numbers can be predictable. Applications that have strong pseudorandom number requirements must use a generator that is known to be sufficient for their needs.
The following noncompliant code generates an ID with a numeric part produced by calling the rand() function. The IDs produced are predictable and have limited randomness.
This compliant solution replaces the rand() function with the POSIX random() function:
The POSIX random() function is a better pseudorandom number generator. Although on some platforms the low dozen bits generated by rand() go through a cyclic pattern, all the bits generated by random() are usable. The rand48 family of functions provides another alternative for pseudorandom numbers.
Although not specified by POSIX, arc4random() is another possibility for systems that support it. The arc4random(3) manual page [OpenBSD] states
++... provides higher quality of data than those described in rand(3), random(3), and drand48(3).
+
To achieve the best random numbers possible, an implementation-specific function must be used. When unpredictability is crucial and speed is not an issue, as in the creation of strong cryptographic keys, use a true entropy source, such as /dev/random, or a hardware device capable of generating random numbers. The /dev/random device can block for a long time if there are not enough events going on to generate sufficient entropy.
On Windows platforms, the BCryptGenRandom() function can be used to generate cryptographically strong random numbers. The Microsoft Developer Network BCryptGenRandom() reference [MSDN] states:
++The default random number provider implements an algorithm for generating random numbers that complies with the NIST SP800-90 standard, specifically the CTR_DRBG portion of that standard.
+
The use of the rand() function can result in predictable random numbers.
| + Rule + | ++ Severity + | ++ Likelihood + | ++ Remediation Cost + | ++ Priority + | ++ Level + | +
|---|---|---|---|---|---|
| + MSC30-C + | ++ Medium + | ++ Unlikely + | ++ Low + | ++ P6 + | ++ L2 + | +
| + Tool + | ++ Version + | ++ Checker + | ++ Description + | +
|---|---|---|---|
| + + Astrée + + | ++ 20.10 + | ++ stdlib-use-rand + | ++ Fully checked + | +
| + + Axivion Bauhaus Suite + + | ++ 7.2.0 + | ++ CertC-MSC30 + | ++ | +
| + + Clang + + | ++ 4.0 (prerelease) + | +
+ cert-msc30-c
+ |
+
+ Checked by
+ clang-tidy
+ |
+
| + + CodeSonar + + | ++ 6.2p0 + | ++ BADFUNC.RANDOM.RAND + | ++ Use of rand + | +
| + + Compass/ROSE + + | ++ | ++ | ++ | +
| + + Coverity + + | ++ 2017.07 + | ++ DONTCALL + | ++ Implemented - weak support + | +
| + + ECLAIR + + | ++ 1.2 + | ++ CC2.MSC30 + | ++ Fully implemented + | +
| + + Helix QAC + + | ++ 2022.1 + | ++ C5022 + C++5029 + | ++ | +
| + + Klocwork + + | ++ 2022.1 + | ++ CERT.MSC.STD_RAND_CALL + | ++ | +
| + + LDRA tool suite + + | ++ 9.7.1 + | ++ 44 S + | ++ Enhanced enforcement + | +
| + + Parasoft C/C++test + + | ++ 2021.2 + | ++ CERT_C-MSC30-a + | ++ Do not use the rand() function for generating pseudorandom numbers + | +
| + + PC-lint Plus + + | ++ 1.4 + | ++ 586 + | ++ Fully supported + | +
| + + Polyspace Bug Finder + + | ++ R2021a + | ++ + CERT C: Rule MSC30-C + + | ++ Checks for vulnerable pseudo-random number generator (rule fully covered) + | +
| + + PRQA QA-C + + | ++ 9.7 + | ++ 5022 + | ++ Fully implemented + | +
| + + PRQA QA-C++ + + | ++ 4.4 + | ++ 5029 + | ++ | +
| + + RuleChecker + + | ++ 20.10 + | ++ stdlib-use-rand + | ++ Fully checked + | +
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
+Key here (explains table format and definitions)
+| + Taxonomy + | ++ Taxonomy item + | ++ Relationship + | +
|---|---|---|
| + + CERT C + + | ++ + MSC50-CPP. Do not use std::rand() for generating pseudorandom numbers + + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
| + + CERT Oracle Secure Coding Standard for Java + + | ++ + MSC02-J. Generate strong random numbers + + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
| + + CWE 2.11 + + | ++ + CWE-327 + + , Use of a Broken or Risky Cryptographic Algorithm + | ++ 2017-05-16: CERT: Rule subset of CWE + | +
| + + CWE 2.11 + + | ++ + CWE-330 + + , Use of Insufficiently Random Values + | ++ 2017-06-28: CERT: Rule subset of CWE + | +
| + + CWE 2.11 + + | ++ + CWE-338 + + , Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) + | ++ 2017-06-28: CERT: Rule subset of CWE + | +
| + + CWE 2.11 + + | ++ + CWE-676 + + | ++ 2017-05-18: CERT: Rule subset of CWE + | +
Key here for mapping notes
+CWE-327 and MSC30-C
+CWE-338 and MSC30-C
+CWE-338 = Union( MSC30-C, list) where list =
+CWE-330 and MSC30-C
+Independent( MSC30-C, MSC32-C, CON33-C)
+CWE-330 = Union( MSC30-C, MSC32-C, CON33-C, list) where list = other improper use or creation of random values. (EG the would qualify)
+MSC30-C, MSC32-C and CON33-C are independent, they have no intersections. They each specify distinct errors regarding PRNGs.
+CWE-676 and MSC30-C
+| + [ + + MSDN + + ] + | ++ " + + BCryptGenRandom() Function + + " + | +
| + [ + + OpenBSD + + ] + | ++ + arc4random() + + | +
This query implements the CERT-C rule MSC30-C:
+++Do not use the rand() function for generating pseudorandom numbers
+
A pseudorandom number generator (PRNG) is a deterministic algorithm capable of generating sequences of numbers that approximate the properties of random numbers. Each sequence is completely determined by the initial state of the PRNG and the algorithm for changing the state. Most PRNGs make it possible to set the initial state, also called the seed state. Setting the initial state is called seeding the PRNG.
+Calling a PRNG in the same initial state, either without seeding it explicitly or by seeding it with the same value, results in generating the same sequence of random numbers in different runs of the program. Consider a PRNG function that is seeded with some initial seed value and is consecutively called to produce a sequence of random numbers, S. If the PRNG is subsequently seeded with the same initial seed value, then it will generate the same sequence S.
As a result, after the first run of an improperly seeded PRNG, an attacker can predict the sequence of random numbers that will be generated in the future runs. Improperly seeding or failing to seed the PRNG can lead to vulnerabilities, especially in security protocols.
+The solution is to ensure that the PRNG is always properly seeded. A properly seeded PRNG will generate a different sequence of random numbers each time it is run.
+Not all random number generators can be seeded. True random number generators that rely on hardware to produce completely unpredictable results do not need to be and cannot be seeded. Some high-quality PRNGs, such as the /dev/random device on some UNIX systems, also cannot be seeded. This rule applies only to algorithmic pseudorandom number generators that can be seeded.
This noncompliant code example generates a sequence of 10 pseudorandom numbers using the random() function. When random() is not seeded, it behaves like rand(), producing the same sequence of random numbers each time any program that uses it is run.
The output is as follows:
+Call srandom() before invoking random() to seed the random sequence generated by random(). This compliant solution produces different random number sequences each time the function is called, depending on the resolution of the system clock:
The output is as follows:
+This may not be sufficiently random for concurrent execution, which may lead to correlated generated series in different threads. Depending on the application and the desired level of security, a programmer may choose alternative ways to seed PRNGs. In general, hardware is more capable than software of generating real random numbers (for example, by sampling the thermal noise of a diode).
+The BCryptGenRandom() function does not run the risk of not being properly seeded because its arguments serve as seeders:
+The output is as follows:
+| + Rule + | ++ Severity + | ++ Likelihood + | ++ Remediation Cost + | ++ Priority + | ++ Level + | +
|---|---|---|---|---|---|
| + MSC32-C + | ++ Medium + | ++ Likely + | ++ Low + | ++ P18 + | ++ L1 + | +
| + Tool + | ++ Version + | ++ Checker + | ++ Description + | +
|---|---|---|---|
| + + Astrée + + | ++ 20.10 + | ++ | ++ Supported, but no explicit checker + | +
| + + Axivion Bauhaus Suite + + | ++ 7.2.0 + | ++ CertC-MSC32 + | ++ | +
| + + Helix QAC + + | ++ 2022.1 + | ++ C5031 + C++5036 + | ++ | +
| + + Klocwork + + | ++ 2022.1 + | ++ CERT.MSC.SEED_RANDOM + | ++ | +
| + + PC-lint Plus + + | ++ 1.4 + | ++ 2460, 2461, 2760 + | ++ Fully supported + | +
| + + Polyspace Bug Finder + + | ++ R2021a + | ++ + CERT C: Rule MSC32-C + + | ++ Checks for: + Deterministic random output from constant seedeterministic random output from constant seed, predictable random output from predictable seedredictable random output from predictable seed. + Rule fully covered. + | +
| + + Parasoft C/C++test + + | ++ 2021.2 + | ++ CERT_C-MSC32-d + | ++ Properly seed pseudorandom number generators + | +
| + + PRQA QA-C + + | ++ 9.7 + | ++ 5031 + | ++ | +
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
+Key here (explains table format and definitions)
+| + Taxonomy + | ++ Taxonomy item + | ++ Relationship + | +
|---|---|---|
| + + CERT C Secure Coding Standard + + | ++ + MSC30-C. Do not use the rand() function for generating pseudorandom numbers + + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
| + + CERT C + + | ++ + MSC51-CPP. Ensure your random number generator is properly seeded + + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
| + + CWE 2.11 + + | ++ + CWE-327 + + , Use of a Broken or Risky Cryptographic Algorithm + | ++ 2017-05-16: CERT: Rule subset of CWE + | +
| + + CWE 2.11 + + | ++ + CWE-330 + + , Use of Insufficiently Random Values + | ++ 2017-06-28: CERT: Rule subset of CWE + | +
| + + CWE 2.11 + + | ++ + CWE-331 + + , Insufficient Entropy + | ++ 2017-06-28: CERT: Exact + | +
Key here for mapping notes
+CWE-327 and MSC32-C
+CWE-330 and MSC32-C
+Independent( MSC30-C, MSC32-C, CON33-C)
+CWE-330 = Union( MSC30-C, MSC32-C, CON33-C, list) where list = other improper use or creation of random values. (EG the would qualify)
+MSC30-C, MSC32-C and CON33-C are independent, they have no intersections. They each specify distinct errors regarding PRNGs.
+| + [ + + MSDN + + ] + | ++ " + + BCryptGenRandom() Function + + " + | +
This query implements the CERT-C rule MSC32-C:
+++Properly seed pseudorandom number generators
+
If control reaches the closing curly brace (}) of a non-void function without evaluating a return statement, using the return value of the function call is undefined behavior. (See undefined behavior 88.)
In this noncompliant code example, control reaches the end of the checkpass() function when the two strings passed to strcmp() are not equal, resulting in undefined behavior. Many compilers will generate code for the checkpass() function, returning various values along the execution path where no return statement is defined.
This error is frequently diagnosed by compilers. (See MSC00-C. Compile cleanly at high warning levels.)
+This compliant solution ensures that the checkpass() function always returns a value:
In this noncompliant code example, control reaches the end of the getlen() function when input does not contain the integer delim. Because the potentially undefined return value of getlen() is later used as an index into an array, a buffer overflow may occur.
Implementation Details (GCC)
+Violating this rule can have unexpected consequences, as in the following example:
+When this program is compiled with -Wall on most versions of the GCC compiler, the following warning is generated:
None of the inputs to the function equal the delimiter, so when run with GCC 5.3 on Linux, control reaches the end of the getlen() function, which is undefined behavior and in this test returns 3, causing an out-of-bounds write to the data array.
This compliant solution changes the interface of getlen() to store the result in a user-provided pointer and returns a status indicator to report success or failure. The best method for handling this type of error is specific to the application and the type of error. (See ERR00-C. Adopt and implement a consistent and comprehensive error-handling policy for more on error handling.)
MSC37-C-EX1: According to the C Standard, 5.1.2.2.3, paragraph 1 [ISO/IEC 9899:2011], "Reaching the } that terminates the main function returns a value of 0." As a result, it is permissible for control to reach the end of the main() function without executing a return statement.
MSC37-C-EX2: It is permissible for a control path to not return a value if that code path is never taken and a function marked _Noreturn is called as part of that code path. For example:
Using the return value from a non-void function where control reaches the end of the function without evaluating a return statement can lead to buffer overflow vulnerabilities as well as other unexpected program behaviors.
| + Rule + | ++ Severity + | ++ Likelihood + | ++ Remediation Cost + | ++ Priority + | ++ Level + | +
|---|---|---|---|---|---|
| + MSC37-C + | ++ High + | ++ Unlikely + | ++ Low + | ++ P9 + | ++ L2 + | +
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
+| + Tool + | ++ Version + | ++ Checker + | ++ Description + | +
|---|---|---|---|
| + + Astrée + + | ++ 20.10 + | ++ return-implicit + | ++ Fully checked + | +
| + + Axivion Bauhaus Suite + + | ++ 7.2.0 + | ++ CertC-MSC37 + | ++ | +
| + + CodeSonar + + | ++ 6.2p0 + | ++ LANG.STRUCT.MRS + | ++ Missing return statement + | +
| + + Coverity + + | ++ 2017.07 + | ++ MISSING_RETURN + | ++ Implemented + | +
| + + Helix QAC + + | ++ 2022.1 + | ++ C2888 + C++2888, C++4022 + | ++ | +
| + + Klocwork + + | ++ 2022.1 + | ++ FUNCRET.GEN + FUNCRET.IMPLICIT + | ++ | +
| + + LDRA tool suite + + | ++ 9.7.1 + | ++ 2 D, 36 S, 66 S + | ++ Fully implemented + | +
| + + Parasoft C/C++test + + | ++ 2021.2 + | ++ CERT_C-MSC37-a + | ++ All exit paths from a function with non-void return type shall have an explicit return statement with an expression + | +
| + + PC-lint Plus + + | ++ 1.4 + | ++ 533 + | ++ Fully supported + | +
| + + Polyspace Bug Finder + + | ++ R2021a + | ++ + CERT C: Rule MSC37-C + + | ++ Checks for missing return statement (rule fully covered) + | +
| + + PRQA QA-C + + | ++ 9.7 + | ++ 2888 + | ++ | +
| + + PRQA QA-C++ + + | ++ 4.4 + | ++ 2888, 4022 + | ++ | +
| + + RuleChecker + + | ++ 20.10 + | ++ return-implicit + | ++ Fully checked + | +
| + + SonarQube C/C++ Plugin + + | ++ 3.11 + | ++ S935 + | ++ | +
| + + TrustInSoft Analyzer + + | ++ 1.38 + | ++ Body of function falls-through + | ++ Exhaustively verified. + | +
Key here (explains table format and definitions)
+| + Taxonomy + | ++ Taxonomy item + | ++ Relationship + | +
|---|---|---|
| + + CERT C Secure Coding Standard + + | ++ + MSC01-C. Strive for logical completeness + + | ++ Prior to 2018-01-12: CERT: Unspecified Relationship + | +
| + + CWE 2.11 + + | ++ + CWE-758 + + | ++ 2017-07-07: CERT: Rule subset of CWE + | +
Key here for mapping notes
+CWE-758 and MSC37-C
+Independent( INT34-C, INT36-C, MEM30-C, MSC37-C, FLP32-C, EXP33-C, EXP30-C, ERR34-C, ARR32-C)
+CWE-758 = Union( MSC37-C, list) where list =
+Undefined behavior that results from anything other than failing to return a value from a function that expects one
+| + [ + + ISO/IEC 9899:2011 + + ] + | ++ 5.1.2.2.3, "Program Termination" + | +
This query implements the CERT-C rule MSC37-C:
+++Ensure that control never reaches the end of a non-void function
+
+ ... +
+ ++ ... +
+This query implements the CERT-C rule STR30-C:
+++Do not attempt to modify string literals
+
+ ... +
+ ++ ... +
+This query implements the CERT-C rule STR31-C:
+++Guarantee that storage for strings has sufficient space for character data and the null terminator
+
+ ... +
+ ++ ... +
+This query implements the CERT-C rule STR32-C:
+++Do not pass a non-null-terminated character sequence to a library function that expects a string
+
None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-None
-