[LLVMbugs] [Bug 16772] New: False positive with -Wcast-align for already-aligned struct member

[bugzilla-daemon at llvm.org]

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

            Bug ID: 16772
           Summary: False positive with -Wcast-align for already-aligned
                    struct member
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: pgut001 at cs.auckland.ac.nz
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

A common idiom for reserving storage within a struct is to have an array of
char (or unsighed char) that you then cast to whatever you want.  Zero-length
arrays are an obvious example.  Problem is that when compiled with
-Wcast-align, clang complains about an alignment issue even though the array is
preceded by an alignment-inducing struct member.  For example given the
following:

> cat > ./thing.c <<EOF
typedef struct {
  int thing1;
  char thing2;
  void *thing3;
  } THING_STRUCT;

typedef struct {
  void *nextThing;
  char data[ 100 ];
  } THING_STORAGE_STRUCT;

int main( void )
  {
  THING_STRUCT *thingPtr;
  THING_STORAGE_STRUCT thingStorage;

  thingPtr = ( THING_STRUCT * ) thingStorage.data;

  return( 0 );
  }
EOF

> clang -Wcast-align thing.c

I get:

thing.c:17:13: warning: cast from 'char *' to 'THING_STRUCT *' increases
required
      alignment from 1 to 8 [-Wcast-align]
        thingPtr = ( THING_STRUCT * ) thingStorage.data;
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.

Given that thingStorage.data is preceded by a pointer member which should
ensure that the data member is aligned as required, it seems like this is a
false positive.

-- 
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/20130802/f7531218/attachment.html>