title: Is it well-defined to hold a misaligned pointer, as long as you don't ever dereference it?
body: <p>I have some C code that parses packed/unpadded binary data that comes in from the network.</p>
  
  <p>This code was/is working fine under Intel/x86, but when I compiled it under ARM it would often crash.  </p>
  
  <p>The culprit, as you might have guessed, was unaligned pointers -- in particular, the parsing code would do questionable things like this:</p>
  
  <pre><code>uint8_t buf[2048];
  [... code to read some data into buf...]
  int32_t nextWord = *((int32_t *) &amp;buf[5]);  // misaligned access -- can crash under ARM!
  </code></pre>
  
  <p>... that's obviously not going to fly in ARM-land, so I modified it to look more like this:</p>
  
  <pre><code>uint8_t buf[2048];
  [... code to read some data into buf...]
  int32_t * pNextWord = (int32_t *) &amp;buf[5];
  int32 nextWord;
  memcpy(&amp;nextWord, pNextWord, sizeof(nextWord));  // slower but ARM-safe
  </code></pre>
  
  <p>My question (from a language-lawyer perspective) is:  is my "ARM-fixed" approach well-defined under the C language rules?</p>
  
  <p>My worry is that maybe even just having a misaligned-int32_t-pointer might be enough to invoke undefined behavior, even if I never actually dereference it directly.  (If my concern is valid, I think I could fix the problem by changing <code>pNextWord</code>'s type from <code>(const int32_t *)</code> to <code>(const char *)</code>, but I'd rather not do that unless it's actually necessary to do so, since it would mean doing some pointer-stride arithmetic by hand)</p>