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 [ISO/IEC 9899:2011] 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 programs that rely on this behavior to fail abnormally.

...

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.

...

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 recommendation INT14-C. Avoid performing bitwise and arithmetic operations on the same data.

...

unsigned int ui1, ui2, sum;

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

...

The GNU libc implementation of strerror_r declares the function to return char*, in conflict with the POSIX ^® specification. The following 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[80];
  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.

...

#define _XOPEN_SOURCE 600
#include <string.h>

void f() {
  char buf[80];
  int result;

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

  if (0 != result)
    strcpy(buf, "Unknown error");

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

...

CERT C++ Secure Coding Standard: MSC14-CPP. Do not introduce unnecessary platform dependencies

ISO/IEC 9899:1999 Section 2011 Section 3.4.1, "implementationImplementation-defined behavior," Section 3.4.4, "unspecified Unspecified behavior," Appendix  Section J.1, "Unspecified behavior," and Appendix Section J.3, "Implementation-defined behavior"

ISO/IEC TR 24772 "BQF Unspecified Behaviourbehaviour"

...

Sources

[Dowd 2006] Chapter 6, "C Language Issues" ("Arithmetic Boundary Conditions," pp. 211-223211–223)
[Seacord 2005a] Chapter 5, "Integers"

...