Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The definition of pointer arithmetic from The the C++ Standard, [expr.add], paragraph 7, states [ISO/IEC 14882-2014], states the following:

For addition or subtraction, if the expressions P or Q have type “pointer to cv T”, where T is different from the cv-unqualified array element type, the behavior is undefined. [Note: In particular, a pointer to a base class cannot be used for pointer arithmetic when the array contains objects of a derived class type. —end note]

Pointer arithmetic does not account for polymorphic object sizes, and attempting to perform pointer arithmetic on a polymorphic object value results in undefined behavior.

The C++ StardardStandard, [expr.sub], paragraph 11 [ISO/IEC 14882-2014], defines array subscripting as being identical to pointer arithmetic. Specifically, it states the following:

The expression E1[E2] is identical (by definition) to *((E1)+(E2))...

Do not use pointer arithmetic, including array subscripting, on polymorphic objects.

Noncompliant Code Example

In this noncompliant code example, f() accepts an array of S objects as its first parameter. However, main() passes an array of T objects as the first argument to f(), which results in undefined behavior due to the pointer arithmetic used within the for loopThe following code examples assume the following static variables and class definitions.

Code Block
#FFCCCC
bgColorlanguagelangcpp
#include <iostream>

int GlobIglobI;
double GlobDglobD;

struct S {
  int Ii;
  
  S() : Ii(GlobIglobI++) {}
};

struct T : S {
  double Dd;
  
  T() : S(), Dd(GlobDglobD++) {}
};

Noncompliant Code Example (Pointer Arithmetic)

In this noncompliant code example, f() accepts an array of S objects as its first parameter. However, main() passes an array of T objects as the first argument to f(), which results in undefined behavior due to the pointer arithmetic used within the for loop.

Code Block
bgColor#FFCCCC
langcpp
#include <iostream>
 
// ... definitions for S, T, globI, globD ...

void f(const S *SomeSessomeSes, std::size_t Countcount) { 
  for (const S *Endend = SomeSessomeSes + Countcount; SomeSessomeSes != Endend; ++SomeSessomeSes) {
    std::cout << SomeSessomeSes->I>i << std::endl;
  }
}

int main() {
  T Testtest[5];
  f(Testtest, 5);
}

This example would still be noncompliant if the for loop had instead been written to use array subscripting, like:

Noncompliant Code Example (Array Subscripting)

In this noncompliant code example, the for loop uses array subscripting. Since array subscripts are computed using pointer arithmetic, this code also results in undefined behavior.

Code Block
bgColor#FFCCCC
langcpp
#include <iostream>
 
// ... definitions for S, T, globI, globD ...

void f(const S *someSes, std::size_t count) { 
  
Code Block
for (std::size_t i = 0; i < Countcount; ++i) {
    std::cout << SomeSessomeSes[i].Ii << std::endl;
  }
}

int main() {
  T test[5];
  f(test, 5);
}

Compliant Solution (Array)

Instead of having an array of objects, an array of pointers solves the problem of the objects being of different sizes, as in this compliant solution:.

Code Block
bgColor#ccccff
langcpp
#include <iostream>

int GlobI;
double GlobD;

struct S {
  int I;
  
  S() : I(GlobI++) {}
};

struct T : S {
  double D;
  
  T() : S(), D(GlobD++) {}
};

// ... definitions for S, T, globI, globD ...

void f(const S * const *SomeSessomeSes, std::size_t Countcount) { 
  for (const S * const *Endend = SomeSessomeSes + Countcount; SomeSessomeSes != Endend; ++SomeSessomeSes) {
    std::cout << (*SomeSessomeSes)->I>i << std::endl;
  }
}

int main() {
  S *Testtest[] = {new T, new T, new T, new T, new T};
  f(Testtest, 5);
  for (auto Vv : Testtest) {
    delete Vv;
  }
}

The elements in the arrays are no longer polymorphic objects (instead, they are pointers to polymorphic objects), and so there is no no undefined behavior with the pointer arithmetic.

Compliant Solution (std::vector)

Another approach is to use an a standard template library (STL) container instead of an array and have f() accept iterators as parameters, as in this compliant solution. However, since because STL containers require homogeneous elements, pointers are still required within the container.

Code Block
bgColor#ccccff
langcpp
#include <iostream>
#include <vector>

int GlobI;
double GlobD;

struct S {
  int I;
  
  S() : I(GlobI++) {}
};

struct T : S {
  double D;
  
  T() : S(), D(GlobD++) {}
};
// ... definitions for S, T, globI, globD ...
template <typename Iter>
void f(Iter Ii, Iter Ee) {
  for (; Ii != Ee; ++Ii) {
    std::cout << (*Ii)->I>i << std::endl;
  }
}

int main() {
  std::vector<S *> Testtest{new T, new T, new T, new T, new T};
  f(Testtest.cbegin(), Testtest.cend());
  for (auto Vv : Testtest) {
    delete Vv;
  }
}

Risk Assessment

Using arrays polymorphically can result in memory corruption, which could lead to an attacker being able to execute arbitrary code.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

CTR39

CTR56-CPP

High

Likely

High

P9

L2

Automated Detection

Tool

Version

Checker

Description

 PRQA QA-

Axivion Bauhaus Suite

Include Page
Axivion Bauhaus Suite_V
Axivion Bauhaus Suite_V

CertC++-CTR56
CodeSonar
Include Page
CodeSonar_V
CodeSonar_V

LANG.STRUCT.PARITH

Pointer Arithmetic

Helix QAC

Include Page
Helix QAC_V
Helix QAC_V

C++
Include Page
3073
Parasoft C/
PRQA QA-
C++test
Include Page
Parasoft_V
PRQA QA-C++_V3072,3073
Parasoft_V

CERT_CPP-CTR56-a
CERT_CPP-CTR56-b
CERT_CPP-CTR56-c

Don't treat arrays polymorphically
A pointer to an array of derived class objects should not be converted to a base class pointer
Do not treat arrays polymorphically

LDRA tool suite
Include Page
LDRA_V
LDRA_V

567 S

Enhanced Enforcement

Polyspace Bug Finder

Include Page
Polyspace Bug Finder_V
Polyspace Bug Finder_V

CERT C++: CTR56-CPPChecks for pointer arithmetic on polymorphic object (rule fully covered)
PVS-Studio

Include Page
PVS-Studio_V
PVS-Studio_V

V777
 

Related Vulnerabilities

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

Related Guidelines

Bibliography

[ISO/IEC 14882-2014]

Subclause 5.7, "Additive Operators"
Subclause 5.2.1, "Subscripting" 

[
Stroustrup 06]What's wrong with arrays?
Lockheed Martin 2005]AV Rule 96, "Arrays shall not be treated polymorphically"
[Meyers
06
1996]Item 3
: Never treat arrays polymorphically
, "Never Treat Arrays Polymorphically"
[Stroustrup 2006]"What's Wrong with Arrays?"
[Sutter 2004
[Lockheed Martin 05]AV Rule 96 Arrays shall not be treated polymorphically.[Sutter 04
]Item 100
:
, "Don't
treat arrays polymorphically

...

Treat Arrays Polymorphically"


...

Image Modified Image Modified Image Modified