[LLVMbugs] [Bug 22821] New: usage of pointers to packed struct members should trigger warning

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Fri Mar 6 07:38:30 PST 2015


http://llvm.org/bugs/show_bug.cgi?id=22821

            Bug ID: 22821
           Summary: usage of pointers to packed struct members should
                    trigger warning
           Product: clang
           Version: 3.6
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: sven.koehler at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

clang, like gcc and other compilers, supports packed structs. This feature
exists for years (at least in gcc and microsoft compilers) and the dangers are
well known. In particular, pointers to members of a packed struct are basically
invalid as they don't satisfy the alignment assumptions that compilers usually
make. This results in crashing programs on ARM, SPARC, and maybe other
architectures. Consider the following example code and assume that int is 32
bit:

#include <stdio.h>
#pragma pack(1)
typedef struct { int v; } unaligned;
#pragma pack()
void print(int *x) { printf("%d\n", *x); }
void test1(unaligned *p) { print(&(p->v)); }
void test2(unaligned *p) {
  int *x = &(p->v);
  printf("%d\n", *x);
}


The type unaligned only provides an alignment guarantee of 1. Yet, I can assign
the pointer to p->v to an int* without any complaints by the compiler. I tried
-Weverything in combination with an arm target.

There is -Wcast-align, but it only seems to be triggered when casting char* to
int*. Again, char* only provides an alignment of 1 while int* needs an
alignment of 4.

I guess, the technical challenge here is to distinguish between an ordinary
int* with an alignment of 4 and a some special type of int* with an alignment
of 1. Note that by changing pack(1) into pack(2), we can easily create a struct
with an alignment guarantee of 2, so technically a pointer to an int16_t member
of the struct would be fine while a pointer to an int32_t member would not be
fine. 

I'm aware of some discussion in the GCC bugzilla where they discuss introducing
variable attributes to indicate unaligned pointers and how gcc could track
alignment guarantees inside the scope so that, for example, test2 would work
out of the box. But anyhow, there needs to be some warning when a pointer with
a low alignment guarantee is assigned to some pointer variable with high
alignment guarantee as this will break on some architectures.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150306/452fc30e/attachment.html>


More information about the llvm-bugs mailing list