CertC-EXP19ΒΆ
Use braces for the body of an if, for, or while statement
Required inputs: IR
Opening and closing braces for
if,
for, and
while statements should always be used even if the statement's
body contains only a single statement.
If an
if,
while, or
for statement is used in a macro, the macro definition should not
conclude with a semicolon. (See
PRE11-C.
Do not conclude macro definitions with a semicolon.)
Braces improve the uniformity and readability of code. More important, when inserting an additional statement into a body containing only a single statement, it is easy to forget to add braces because the indentation gives strong (but misleading) guidance to the structure.
Braces also help ensure that macros with multiple statements are properly
expanded. Such a macro should be wrapped in a
do-while loop. (See
PRE10-C.
Wrap multistatement macros in a do-while loop.) However, when the
do-while loop is not present, braces can still ensure that the
macro expands as intended.
Noncompliant Code Example
This noncompliant code example uses an
if statement without braces to authenticate a user:
int login; if (invalid_login()) login = 0; else login = 1;
A developer might add a debugging statement to determine when the login is valid but forget to add opening and closing braces:
int login;
if (invalid_login())
login = 0;
else
printf("Login is valid\n"); /* Debugging line added here */
login = 1; /* This line always gets executed
/* regardless of a valid login! */
Because of the indentation of the code, it is difficult to tell that the code will not function as intended by the programmer, potentially leading to a security breach.
Compliant Solution
In the compliant solution, opening and closing braces are used even when the body is a single statement:
int login;
if (invalid_login()) {
login = 0;
} else {
login = 1;
}
Noncompliant Code Example
This noncompliant code example has an
if statement nested in another
if statement without braces around the
if and
else bodies:
int privileges;
if (invalid_login())
if (allow_guests())
privileges = GUEST;
else
privileges = ADMINISTRATOR;
The indentation could lead the programmer to believe that a user is given
administrator privileges only when the user's login is valid. However, the
else statement actually attaches to the inner
if statement:
int privileges;
if (invalid_login())
if (allow_guests())
privileges = GUEST;
else
privileges = ADMINISTRATOR;
This is a security loophole: users with invalid logins can still obtain administrator privileges.
Compliant Solution
In the compliant solution, adding braces removes the ambiguity and ensures that privileges are correctly assigned:
int privileges;
if (invalid_login()) {
if (allow_guests()) {
privileges = GUEST;
}
} else {
privileges = ADMINISTRATOR;
}
Noncompliant Code Example (empty block)
This noncompliant code example has a
while statement with no block:
while (invalid_login());
Note that if
invalid_login() has no side effects (such as warning the user if
their login failed), this code also violates
MSC12-C.
Detect and remove code that has no effect or is never executed.
Compliant Solution (empty block)
This compliant solution features an explicit empty block, which clarifies the developer's intent:
while (invalid_login()) {}
Risk Assessment
| Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
| EXP19-C | Medium | Probable | Medium | P8 | L2 |
Related Guidelines
| MISRA C:2012 | Rule 15.6 (required) |
Bibliography
| [ GNU 2010] | Coding Standards, Section 5.3, "Clean Use of C Constructs" |
Possible Messages
Key |
Text |
Severity |
Disabled |
|---|---|---|---|
dangerous_else |
Block or if statement required as else branch. |
None |
False |
dangerous_then |
Block required as then branch. |
None |
False |
loop_body_not_compound |
Loop body shall be a statement sequence. |
None |
False |
Options
This rule shares the following common options: exclude_in_macros, exclude_messages_in_system_headers, excludes, extend_exclude_to_macro_invocations, includes, justification_checker, languages, post_processing, provider, report_at, severity
The following places define options that affect this rule: Stylechecks, Analysis-GlobalOptions
This rule has no individual options.