Page History

While it has been common practice to Although programmers often use integers and pointers interchangeably in C, pointer-to-integer and integer-to-pointer conversions are implementation-defined. 

Conversions between integers and pointers can have undesired consequences depending on the implementation.

According to the C Standard, subclause 6.3.2.3 [ISO/IEC 9899:2024], Wiki MarkupThe only value that can be considered interchangeable between pointers and integers is the constant 0. Except in this case, conversions between integers and pointers may have undesired consequences depending on the [implementation|BB. Definitions#implementation]. According to C99 \[[ISO/IEC 9899:1999|AA. C References#ISO/IEC 9899-1999]\]:

An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.

Any pointer type may be converted to an integer type.   Except as previously specified, the result is implementation-defined.   If the result cannot be represented in the integer type, the behavior is undefined.   The result need not be in the range of values of any integer type.

Do not convert an integer type to a pointer type if the resulting pointer is incorrectly aligned, does not point to an entity of the referenced type, or is a trap representation.

Do not convert a pointer type to an integer type if the result cannot be represented in the integer type. (See undefined behavior 23.)

The mapping between pointers and integers These issues arise because the mapping functions for converting a pointer to an integer or an integer to a pointer must be consistent with the addressing structure of the execution environment.   For Issues may arise, for example, not all machines on architectures that have a flat segmented memory model.

It is sometimes necessary in low-level kernel or graphics code to access memory at a specific location, requiring a literal integer-to-pointer conversion, such as the following:

unsigned int *ptr = 0xcfcfcfcf;

...

Noncompliant Code Example

The size of a pointer can be greater than the size of an integer, such as in an implementation where pointers are 64 bits and unsigned integers are 32 bits. This code example is noncompliant on such implementations because the result of converting the 64-bit ptr cannot be represented in the 32-bit integer type:

void f(void) {
  char *ptr;
  /* ... */
  unsigned int number = (unsigned int)ptr;
  /* ... */
}

Compliant Solution

Any valid pointer to void can be converted to intptr_t or uintptr_t and back with no change in value. (See INT36-EX2.) The C Standard guarantees that a pointer to void may be converted to or from a pointer to any object type and back again and that the result must compare equal to the original pointer. Consequently, converting directly from a char * pointer to a uintptr_t, as in this compliant solution, is allowed on implementations that support the uintptr_t type.

#include <stdint.h>
 
void f(void) {
  char *ptr;
  /* ... */
  uintptr_t number = (uintptr_t)ptr;  
  /* ... */
}

Noncompliant Code Example

In this noncompliant code example, the pointer ptr is converted to an integer value.  Both a pointer and an int are assumed to be 32 bits.   The high-order 9 bits of the number are used to hold a flag value, and the result is converted back into a pointer. This example is noncompliant on an implementation where pointers are 64 bits and unsigned integers are 32 bits because the result of converting the 64-bit ptr cannot be represented in the 32-bit integer type.

void func(unsigned int flag) {
  char *ptr;
unsigned int flag;
/* ... */
  unsigned int number = (unsigned int)ptr;
  number = (number & 0x7fffff) | (flag << 23);
  ptr = (char *)number;
}

A similar scheme was used in early versions of Emacs, limiting its portability and preventing the ability to edit files larger than 8MB.

Please note that this noncompliant code example also violates EXP11-C. Do not apply operators expecting one type to data of an incompatible type.

Compliant Solution

Saving a few bits of storage is generally not as important as writing portable code. A struct can be used to provide room This compliant solution uses a struct to provide storage for both the pointer and the flag value.   This solution is portable to machines of different word sizes, both smaller and larger than 32 bits, and works working even when pointers cannot be represented in any integer type. 

struct ptrflag {
  char *pointer;
  unsigned int flag : 9;
} ptrflag;
 
void func(unsigned int flag) {
  char *ptr;
unsigned int flag;
/* ... */
  ptrflag.pointer = ptr;
  ptrflag.flag = flag;
}

Noncompliant Code Example

It is sometimes necessary to access memory at a specific location, requiring a literal integer to pointer conversion. In this noncompliant code, a pointer is set directly to an integer constant, where it is unknown whether the result will be as intended:

unsigned int *g(void) {
  unsigned int *ptr = 0xdeadbeef;
  /* ... */
  return ptr;
} 

The result of this assignment is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.

Compliant Solution

Unfortunately this code cannot be made safe while strictly conforming to ISO C.

...

A particular platform (that is, hardware, operating system, compiler, and Standard C library) might guarantee that a memory address is correctly aligned for the pointer type, and actually contains a value for that type. A common practice is to use addresses that are known to point to hardware that provides valid values.

Exceptions

INT36-C-EX1: The integer value 0 can be converted to a pointer; it becomes the null pointer.

INT36-C-EX2: Any valid pointer to void can be converted to intptr_t or uintptr_t or their underlying types and back again with no change in value. Use of underlying types instead of intptr_t or uintptr_t is discouraged, however, because it limits portability.

#include <assert.h>
#include <stdint.h>
 
void h(void) {
  intptr_t i = (intptr_t)(void *)&i;
  uintptr_t j = (uintptr_t)(void *)&j;
 
  void *ip = (void *)i;
  void *jp = (void *)j;
 
  assert(ip == &i);
  assert(jp == &j);
}

Risk Assessment

Converting from pointer to integer or vice versa results in unportable code that is not portable and may create unexpected pointers to invalid memory locations.

Automated Detection

...

The LDRA tool suite V 7.6.0 can detect violations of this recommendation.

Compass/ROSE can detect violations of this recommendation.

Tool	Version	Checker	Description
Astrée	Include Page Astrée_V Astrée_V	pointer-integral-cast pointer-integral-cast-implicit function-pointer-integer-cast function-pointer-integer-cast-implicit	Fully checked
Axivion Bauhaus Suite	Include Page Axivion Bauhaus Suite_V Axivion Bauhaus Suite_V	CertC-INT36	Fully implemented
Clang	Include Page Clang_V Clang_V	-Wint-to-pointer-cast, -Wint-conversion	Can detect some instances of this rule, but does not detect all
CodeSonar	Include Page CodeSonar_V CodeSonar_V	LANG.CAST.PC.CONST2PTR LANG.CAST.PC.INT	Conversion: integer constant to pointer Conversion: pointer/integer
Compass/ROSE
Coverity	Include Page Coverity_V Coverity_V	PW.POINTER_CONVERSION_LOSES_BITS	Fully implemented
Cppcheck Premium	Include Page Cppcheck Premium_V Cppcheck Premium_V	premium-cert-int36-c	Partially implemented
Helix QAC	Include Page Helix QAC_V Helix QAC_V	C0303, C0305, C0306, C0309, C0324, C0326, C0360, C0361, C0362 C++3040, C++3041, C++3042, C++3043, C++3044, C++3045, C++3046, C++3047, C++3048
Klocwork	Include Page Klocwork_V Klocwork_V	MISRA.CAST.OBJ_PTR_TO_INT.2012
LDRA tool suite	Include Page LDRA_V LDRA_V	439 S, 440 S	Fully implemented
Parasoft C/C++test	Include Page Parasoft_V Parasoft_V	CERT_C-INT36-b	A conversion should not be performed between a pointer to object type and an integer type other than 'uintptr_t' or 'intptr_t'
PC-lint Plus	Include Page PC-lint Plus_V PC-lint Plus_V	4287	Partially supported: reports casts from pointer types to smaller integer types which lose information
Polyspace Bug Finder	Include Page Polyspace Bug Finder_V Polyspace Bug Finder_V	CERT C: Rule INT36-C	Checks for unsafe conversion between pointer and integer (rule partially covered)
PVS-Studio	Include Page PVS-Studio_V PVS-Studio_V	V527, V528, V542, V566, V601, V647, V1091
RuleChecker	Include Page RuleChecker_V RuleChecker_V	pointer-integral-cast pointer-integral-cast-implicit function-pointer-integer-cast function-pointer-integer-cast-implicit	Fully checked
SonarQube C/C++ Plugin	Include Page SonarQube C/C++ Plugin_V SonarQube C/C++ Plugin_V	S1767	Partially implemented

Related Vulnerabilities

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

Other Languages

...

Related Guidelines

Key here (explains table format and definitions)

...

CERT-CWE Mapping Notes

Key here for mapping notes

CWE-758 and INT36-C

Independent( INT34-C, INT36-C, MEM30-C, MSC37-C, FLP32-C, EXP33-C, EXP30-C, ERR34-C, ARR32-C)

CWE-758 = Union( INT36-C, list) where list =

• Undefined behavior that results from anything other than integer <-> pointer conversion

CWE-704 and INT36-C

CWE-704 = Union( INT36-C, list) where list =

• Incorrect (?) typecast that is not between integers and pointers

CWE-587 and INT36-C

Intersection( CWE-587, INT36-C) =

• Setting a pointer to an integer value that is ill-defined (trap representation, improperly aligned, mis-typed, etc)

CWE-587 – INT36-C =

• Setting a pointer to a valid integer value (eg points to an object of the correct t ype)

INT36-C – CWE-587 =

• Illegal pointer-to-integer conversion

Intersection(INT36-C,CWE-466) =  ∅  

Intersection(INT36-C,CWE-466) =  ∅

An example explaining the above two equations follows:

static char x[3];

char* foo() {

  int x_int = (int) x; // x_int = 999 eg

  return x_int + 5; // returns 1004 , violates CWE 466

}

...

int y_int = foo(); // violates CWE-466

char* y = (char*) y_int; //  // well-defined but y may be invalid, violates INT36-C

char c = *y; // indeterminate value, out-of-bounds read, violates CWE-119

Bibliography

...

Image Added Image Added

References

\[[ISO/IEC 9899:1999|AA. C References#ISO/IEC 9899-1999]\] Section 6.3.2.3, "Pointers"
\[[ISO/IEC PDTR 24772|AA. C References#ISO/IEC PDTR 24772]\] "HFC Pointer casting and pointer type changes"
\[[MITRE 07|AA. C References#MITRE 07]\] [CWE ID 466|http://cwe.mitre.org/data/definitions/466.html], "Return of Pointer Value Outside of Expected Range," and [CWE ID 587|http://cwe.mitre.org/data/definitions/587.html], "Assignment of a Fixed Address to a Pointer"

Image Removed      04. Integers (INT)       Image Modified