Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Updated UB references from C11->C23

...

The C Standard, 6.3.2.3, paragraph 7 [ISO/IEC 9899:20112024], states

A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type. If the resulting pointer is not correctly aligned for the referenced the referenced type, the behavior is undefined.

See undefined behavior 2524.

If the misaligned pointer is dereferenced, the program may terminate abnormally. On some architectures, the cast alone may cause a loss of information even if the value is not dereferenced if the types involved have differing alignment requirements.

...

The C Standard allows any object pointer to be cast to and from void *. As a result, it is possible to silently convert from one pointer type to another without the compiler diagnosing the problem by storing or casting a pointer to void * and then storing or casting it to the final type. In this noncompliant code example, loop_function() is passed the char pointer loopchar_ptr but returns an object of type int pointer:

Code Block
bgColor#FFCCCC
langc
int *loop_function(void *v_pointer) {
  /* ... */
  return v_pointer;
}
 
void func(char *loopchar_ptr) {
  int *int_ptr = loop_function(loopchar_ptr);

  /* ... */
}

This example compiles without warning using GCC 4.8 on Ubuntu Linux 14.04. However, vint_pointer can be more strictly aligned than an object of type int char *.

Compliant Solution

Because the input parameter directly influences the return value, and loop_function() returns an object of type int *, the formal parameter v_pointer is redeclared to accept only an object of type int *:

...

EXP36-C-EX1: Some hardware architectures have relaxed requirements with regard to pointer alignment. Using a pointer that is not properly aligned is correctly handled by the architecture, although there might be a performance penalty. On such an architecture, improper pointer alignment is permitted but remains an efficiency problem.

The x86 32- and 64-bit architectures usually impose only a performance penalty for violations of this rule, but under some circumstances, noncompliant code can still exhibit undefined behavior. Consider the following program:

Code Block
bgColor#FFCCCC
langc
#include <stdio.h>
#include <stdint.h>

#define READ_UINT16(ptr)       (*(uint16_t *)(ptr))
#define WRITE_UINT16(ptr, val) (*(uint16_t *)(ptr) = (val))

void compute(unsigned char *b1, unsigned char *b2,
             int value, int range) {
  int i;
  for (i = 0; i < range; i++) {
    int newval = (int)READ_UINT16(b1) + value;
    WRITE_UINT16(b2, newval);
    b1 += 2;
    b2 += 2;
  }
}

int main() {
  unsigned char buffer1[1024];
  unsigned char buffer2[1024];
  printf("Compute something\n");
  compute(buffer1 + 3, buffer2 + 1, 42, 500);
  return 0;
}

This code tries to read short ints (which are 16 bits long) from odd pairs in a character array, which violates this rule. On 32- and 64-bit x86 platforms, this program should run to completion without incident. However, the program aborts with a SIGSEGV due to the unaligned reads on a 64-bit platform running Debian Linux, when compiled with GCC 4.9.4 using the flags  -O3   or  -O2 -ftree-loop-vectorize -fvect-cost-model.

If a developer wishes to violate this rule and use undefined behavior, they must not only ensure that the hardware guarantees the behavior of the object code, but they must also ensure that their compiler, along with its optimizer, also respect these guarantees.


EXP36-C-EX2: If a pointer is known to be correctly aligned to the target type, then a cast to that type is permitted. There are several cases where a pointer is known to be correctly aligned to the target type. The pointer could point to an object declared with a suitable alignment specifier. It could point to an object returned by aligned_alloc(), calloc(), malloc(), or realloc(), as per the C standard, section 7.2224.3, paragraph 1  [ISO/IEC 9899:20112024].

This compliant solution uses the alignment specifier, which is new to C11, to declare the char object c with the same alignment as that of an object of type int. As a result, the two pointers reference equally aligned pointer types:

...

Accessing a pointer or an object that is not properly aligned can cause a program to crash or give erroneous information, or it can cause slow pointer accesses (if the architecture allows misaligned accesses).

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

EXP36-C

Low

Probable

Medium

P4

L3

Automated Detection

Tool

Version

Checker

Description

Astrée
Include Page
Astrée_V
Astrée_V
pointer-cast-alignmentFully checked
Axivion Bauhaus Suite

Include Page
Axivion Bauhaus Suite_V
Axivion Bauhaus Suite_V

CertC-EXP36
CodeSonar
Include Page
CodeSonar_V
CodeSonar_V

LANG.CAST.PC.OBJ

Cast: Object Pointers

Compass/ROSE
 
 


Can detect violations of this rule. However, it does not flag explicit casts to void * and then back to another pointer type

Coverity
Include Page
Coverity_V
Coverity_V

MISRA C 2004 Rule 11.4

MISRA C 2012 Rule 11.1

MISRA C 2012 Rule 11.2

MISRA C 2012 Rule 11.5

MISRA C 2012 Rule 11.7

Implemented
Cppcheck Premium

Include Page
Cppcheck Premium_V
Cppcheck Premium_V

premium-cert-exp36-cPartially implemented

ECLAIR

Include Page
ECLAIR_V
ECLAIR_V

CC2.EXP36

Fully implemented
EDG
   



GCC
Include Page
GCC_V
GCC_V
 

Can detect some violations of this rule when the -Wcast-align flag is used

 

Helix QAC

Include Page
Helix QAC_V
Helix QAC_V

C0326, C3305

C++3033, C++3038


Klocwork
 
Include Page
Klocwork_V
Klocwork_V
 
MISRA.CAST.OBJ_PTR_TO_OBJ_PTR.2012
LDRA tool suite
Include Page
LDRA_V
LDRA_V

94 S, 606 S

Partially implemented
Parasoft C/C++test
9.5MISRA2004-11_4
Include Page
Parasoft_V
Parasoft_V
CERT_C-EXP36-a

Do not cast pointers into more strictly aligned pointer types

PC-lint Plus

Include Page
PC-lint Plus_V
PC-lint Plus_V

2445

Partially supported: reports casts directly from a pointer to a less strictly aligned type to a pointer to a more strictly aligned type

Fully implemented

Polyspace Bug Finder
R2016aUnreliable cast of pointerPointer implicitly cast to different data type

Include Page
Polyspace Bug Finder_V
Polyspace Bug Finder_V

CERT C: Rule EXP36-C

Checks for source buffer misaligned with destination buffer (rule fully covered)

PVS-Studio

Include Page
PVS-Studio_V
PVS-Studio_V

V548, V641V1032

RuleChecker

Include Page
RuleChecker_V
RuleChecker_V

pointer-cast-alignmentFully checked
PRQA QA-C Include PagePRQA QA-C_vPRQA QA-C_v3305Fully implemented

Related Vulnerabilities

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

Related Guidelines

Key here (explains table format and definitions)

Taxonomy

Taxonomy item

Relationship

CERT C
SEI CERT C++ Coding Standard
VOID EXP56-CPP. Do not cast pointers into more strictly aligned pointer typesPrior to 2018-01-12: CERT: Unspecified Relationship
ISO/IEC TR 24772:2013Pointer Casting and Pointer Type Changes [HFC]Prior to 2018-01-12: CERT: Unspecified Relationship
ISO/IEC TS 17961Converting pointer values to more strictly aligned pointer types [alignconv]Prior to 2018-01-12: CERT: Unspecified Relationship
MISRA C:2012Rule 11.1 (required)Prior to 2018-01-12: CERT: Unspecified Relationship
MISRA C:2012Rule 11.2 (required)Prior to 2018-01-12: CERT: Unspecified Relationship
MISRA C:2012Rule 11.5 (advisory)Prior to 2018-01-12: CERT: Unspecified Relationship
MISRA C:2012Rule 11.7 (required)Prior to 2018-01-12: CERT: Unspecified Relationship

Bibliography

...


...

Image Modified Image Modified Image Modified