V1032. Pointer is cast to a more strictly aligned pointer type.

The analyzer has detected a pointer cast from one type to another, which leads to undefined behavior. Objects of different types may be aligned differently, and casting a pointer type may break the alignment. Dereferencing such an incorrect pointer may cause a crash, while performing operations on it may cause data loss.

Consider the following example.

void foo(void) {
  char ch = '1';
  int *int_ptr = (int *)&ch;
  char *char_ptr = (char *)int_ptr;
}

Reading the address of the 'ch' variable and writing it to a pointer of type 'int' could result in data loss. When casting back, the alignment may change.

To avoid this, you can, for example, perform operations on objects of the same type:

void func(void) {
  char ch = '1';
  int i = ch;
  int *int_ptr = &i;
}

or specify the alignment manually:

#include <stdalign.h>

void func(void) {
  alignas(int) char ch = '1';
  int *int_ptr = (int *)&ch;
  char * char_ptr  = (char *)int_ptr;
}

Here is another situation that can be seen in real-life code. A buffer of bytes is allocated on the stack, and the programmer intends to use it to store a structure. This practice is common when working with such structures as BITMAPINFO. This is what it looks like:

typedef struct tagBITMAPINFOHEADER {
  DWORD biSize;
  LONG  biWidth;
  LONG  biHeight;
  WORD  biPlanes;
  WORD  biBitCount;
  DWORD biCompression;
  DWORD biSizeImage;
  LONG  biXPelsPerMeter;
  LONG  biYPelsPerMeter;
  DWORD biClrUsed;
  DWORD biClrImportant;
} BITMAPINFOHEADER, *PBITMAPINFOHEADER;
....
typedef struct tagBITMAPINFO {
  BITMAPINFOHEADER bmiHeader;
  RGBQUAD          bmiColors[1];
} BITMAPINFO, *LPBITMAPINFO, *PBITMAPINFO;

As you can see, the structure contains variables of types DWORD, LONG, and so on, which must be properly aligned. Moreover, 'bmiColors' is not actually a one-element array; it will contain as many elements as needed – that is why this structure can be created using an array of bytes. The result is the following dangerous code, which you may occasionally see in applications:

void foo()
{
  BYTE buffer[sizeof(BITMAPINFOHEADER) + 3 * sizeof(RGBQUAD)] = {0};
  BITMAPINFO *pBMI = (BITMAPINFO*)buffer;
  ....
}

The buffer on the stack is very likely to become 8-byte aligned, and the code will work. However, it is extremely fragile! Adding just one variable to the beginning of the function could break it all.

Incorrect code:

void foo()
{
  char x;
  BYTE buffer[sizeof(BITMAPINFOHEADER) + 3 * sizeof(RGBQUAD)] = {0};
  BITMAPINFO *pBMI = (BITMAPINFO*)buffer;
  ....
}

Now the 'buffer' is very likely to start with an unaligned address. The size of the 'x' variable is the same as the size of the 'buffer' array's elements, so the buffer can be located on the stack right after the 'x' variable without any offset (alignment).

It depends on the compiler, of course, and you may be lucky again to have the program run correctly. But hopefully we have made it clear why this practice is not a good one.

This problem can be overcome by creating an array in dynamic memory. The allocated memory block will always be aligned according to whatever type is stored in it.

Fixed code:

void foo()
{
  char x;
  BITMAPINFO *pBMI = (BITMAPINFO *)
    calloc(sizeof(BITMAPINFOHEADER) + 3 * sizeof(RGBQUAD),
           sizeof(BYTE));
  ....
}

This diagnostic is classified as: