Page History

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 C Standard identifies four different kinds of non-portable nonportable behavior. Each section of Annex J of the C99 standard C Standard enumerates distinct instances of behaviors of each kind.

An example of undefined behavior is passing a NULL a null char* pointer as an argument to the printf function corresponding to the %s format specification. While  Although some implementations (such as the GNU C Library) provide well-defined semantics for this case, others do not and cause , causing programs that rely on this behavior to fail abnormally.

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

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

Most legitimate platform dependencies can and should be isolated in separate modules that expose portable, platform-agnostic interfaces to platform-specific implementations. Portable applications that cannot avoid relying on platform-specific details should always provide a generic, portable, standards-based solution as a fallback mechanism for the platform-specific alternative. That way, such an application can be more easily ported to new platforms , without an excessive risk of security flaws caused by assumptions that do not hold in the new environment.

...

This noncompliant code example uses the complement operator in the test for unsigned integer overflow. It assumes both numbers are nonnegative:

unsignedsigned int si;
signed int ui1, ui2, sum;
si2;
signed int sum;

if (si < 0 || si2 < 0) {
  /* Handle error condition */
}
if (~ui1~si < ui2si2) {
  /* handleHandle error condition */
}
sum = ui1si + ui2si2;

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

...

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

unsigned int si;
unsigned int ui1, ui2,si2;
unsigned int sum;

if (UINTsi < 0 || si2 < 0) {
  /* Handle error condition */
}
if (INT_MAX - ui1si < ui2si2) {
  /* handleHandle error condition */
}
sum = ui1si + ui2si2;

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

...

The GNU libc implementation of strerror_r declares the function to return char*, in conflict with the POSIX ^® specification. The following This noncompliant code example relies on this return type to pass the return value as an argument to the %s formatting directive to fprintf. The behavior of the example will be undefined on a platform that declares the return type of strerror_r() to be int, in accordance with POSIX.

void f() {
  char buf[80BUFSIZ];
  fprintf(stderr, "Error: %s\n",
          strerror_r(errno, buf, sizeof buf));
}

...

Compliant Solution (strerror_r)

The compliant solution below disables the non-conforming nonconforming declaration of strerror_r() by explicitly requesting POSIX conformance before including the <string.h> header that declares the function and handles the function's failure by copying the "Unknown error" string into the buffer. An alternate solution is to use the strerror_s() function defined by Annex K.

Note that the function assigns the result of the call to strerror_r() to a variable of type int. This assignment is a defense-in-depth strategy guarding against inadvertently invoking strerror_r() that returns char*: a conforming compiler is required to issue a diagnostic for the ill-formed conversion from char* to int.

#define _XOPEN_SOURCE 600
#include <string.h>

void f() {
  char buf[80];

  if (0 != strerror_r(errno, buf, sizeof buf))
    strcpy(buf, "Unknown error");

  fprintf(stderr, "Error: %s\n", buf);
}

The following alternate compliant solution avoids relying on the return type of strerror_r and takes care to set the first character of the buffer to NUL before calling the function to detect its success or failure and copies the "Unknown error" string into the buffer on failure.

#include <stdio.h>
#include <errno.h>
void f() {
  char buf[80BUFSIZ];

  buf[0] = '\0'int result;

  result = strerror_r(errno, buf, sizeof buf);

  if ('\0' =!= buf[0])result) {
    strcpy(buf, "Unknown error");
  }
  fprintf(stderr, "Error: %s\n", buf);
}

...

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

Automated Detection

Related Vulnerabilities

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

Other Languages

...

Related Guidelines

...

...

...

Bibliography

...

Image Added Image Added

References

\[[Dowd 06|AA. References#Dowd 06]\] Chapter 6, "C Language Issues" (Arithmetic Boundary Conditions, pp. 211-223)
\[[ISO/IEC 9899:1999|AA. References#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|AA. References#ISO/IEC PDTR 24772]\] "BQF Unspecified Behaviour"
\[[Seacord 05a|AA. References#Seacord 05]\] Chapter 5, "Integers"

Image Removed      49. Miscellaneous (MSC)      Image Modified