You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 24 Next »

Platform dependencies may be introduced to improve performance on a particular platform. This can be a dangerous practice, particularly if these dependencies are not appropriately documented during development and addressed during porting. Platform dependencies that have no performance or other benefits should consequently be avoided because they may introduce errors during porting.

The C99 standard identifies four different kinds of non-portable behavior. Each section of Annex J of the C99 standard enumerates distinct instances of behaviors of each kind.

Nonportable Behavior

Definition

Annex J Section

unspecified behavior

Behavior for which the standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance.

J.1

undefined behavior

Behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which the standard imposes no requirements. An example of undefined behavior is the behavior on integer overflow.

J.2

implementation-defined behavior

Unspecified behavior whereby each implementation documents how the choice is made.

J.3

locale-specific behavior

Behavior that depends on local conventions of nationality, culture, and language that each implementation documents.

J.4

An example of implementation-defined behavior is the propagation of the high-order bit when a signed integer is shifted right.

An example of unspecified behavior is the order in which the arguments to a function are evaluated.

Most legitimate platform dependencies can and should be isolated in separate modules that use portable interfaces but platform-specific implementations.

Noncompliant Code Example

This noncompliant code example uses the complement operator in the test for unsigned integer overflow.

unsigned int ui1, ui2, sum;

if (~ui1 < ui2) {
  /* handle error condition */
}
sum = ui1 + ui2;

This code assumes that the implementation uses two's complement representation. This assumption is commonly true, but not guaranteed by the standard.

This code sample also violates INT14-C. Avoid performing bitwise and arithmetic operations on the same data.

Compliant Solution

This compliant solution implements a strictly conforming test for unsigned overflow.

unsigned int ui1, ui2, sum;

if (UINT_MAX - ui1 < ui2) {
  /* handle error condition */
}
sum = ui1 + ui2;

If the noncompliant form of this test is truly faster, talk to your compiler vendor, because if these tests are equivalent, optimization should occur. If both forms have the same performance, prefer the portable form.

Risk Assessment

Unnecessary platform dependencies are, by definition, unnecessary. Avoiding these dependencies can eliminate porting errors resulting from invalidated assumptions.

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

MSC14-C

low

unlikely

medium

P2

L3

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Other Languages

This rule appears in the C++ Secure Coding Standard as MSC14-CPP. Do not introduce unnecessary platform dependencies.

References

[[Dowd 06]] Chapter 6, "C Language Issues" (Arithmetic Boundary Conditions, pp. 211-223)
[[ISO/IEC 9899:1999]] Section 3.4.1, "implementation-defined behavior," Section 3.4.4, "unspecified behavior," Appendix J.1, "Unspecified behavior," and Appendix J.3, "Implementation-defined behavior"
[[ISO/IEC PDTR 24772]] "BQF Unspecified Behaviour"
[[Seacord 05a]] Chapter 5, "Integers"


      49. Miscellaneous (MSC)      

  • No labels