title: Allowing struct field to overflow to the next field
body: <p>Consider the following simple example:</p>
  <pre class="lang-c prettyprint-override"><code>struct __attribute__ ((__packed__)) {
   int code[1];
   int place_holder[100];
  } s;
  
  void test(int n)
  {
   int i;
  
   for (i = 0; i &lt; n; i++) {
    s.code[i] = 1;
   }
  }
  </code></pre>
  <p>The for-loop is writing to the field <code>code</code>, which is of size 1. The next field after <code>code</code> is <code>place_holder</code>.<br />
  I would expect that in case of <code>n &gt; 1</code>, the write to <code>code</code> array would overflow and <code>1</code> would be written to <code>place_holder</code>.</p>
  <p>However, when compiling with <code>-O2</code> (on gcc 4.9.4 but probably on other versions as well) something interesting happens.<br />
  The compiler identifies that the code might overflow array <code>code</code>, and <strong>limits loop unrolling to 1 iteration</strong>.</p>
  <p>It's easy to see that when compiling with <code>-fdump-tree-all</code> and looking at the last tree pass (&quot;t.optimized&quot;):</p>
  <pre><code>
  ;; Function test (test, funcdef_no=0, decl_uid=1366, symbol_order=1)
  
  Removing basic block 5
  test (int n)
  {
    &lt;bb 2&gt;:
    # DEBUG i =&gt; 0
    # DEBUG i =&gt; 0
    if (n_4(D) &gt; 0)
      goto &lt;bb 3&gt;;
    else
      goto &lt;bb 4&gt;;
  
    &lt;bb 3&gt;:
    s.code[0] = 1;
    # DEBUG i =&gt; 1
    # DEBUG i =&gt; 1
  
    &lt;bb 4&gt;:
    return;
  
  }
  </code></pre>
  <p>So in this case the compiler completely unrolled the loop to a single iteration.</p>
  <h3>My questions are:</h3>
  <ol>
  <li>From C specification viewpoint, is overflowing (deliberately) from one struct member to the next is illegal or undefined behavior?<br />
  Let's assume I'm aware of the struct layout in memory and know what I'm doing when deliberately overflowing the <code>code</code> array.</li>
  <li>Is there a way to prevent gcc from unrolling the loop in such case? I know I can completely prevent loop unrolling, however I'm still interested in loop unrolling on other cases. I also suspect that the analysis the compiler is doing might affect passes other than loop unrolling.<br />
  gcc is assuming I'm not going to overflow when accessing my array, so what I'm really looking for is way to tell the compiler not to take this assumption (by providing some compiler option).</li>
  </ol>
  <p>I'm aware it's a bad practice to write such code that overflows from one field to another, and I'm not intending to write such code.<br />
  I'm also aware of the practice to put an array (possibly zero sized) as the <strong>last</strong> struct field to allow it to overflow, this is well supported by compilers, while in this case the array <code>code</code> is not the last field.<br />
  So this is not a question of &quot;how to fix the code&quot;, but rather a question of understanding the compiler assumptions and affecting them.</p>
  <p>These questions came up when I observed existing code that was already written in such way, and debugged it to find out why it's not behaving as the original developer expected it to behave.<br />
  The risk is that there are other places in the code where such problem exists. Static analysis tools can help to find out, but I would also like to know if there's a way to make the compiler tolerate such code and still generate the result we would expect.</p>
  <h1>Update</h1>
  <p>I got clear answer to question (1) above, but not for question (2).</p>
  <ul>
  <li>Can gcc allow this as an extension, by some compile options?</li>
  <li>Is there a way to at least get a warning when gcc identifies it? (and it clearly identifies it, by optimizing things out).<br />
  That's important in order to identify such cases in a large existing code base.</li>
  </ul>