Post History

Here's a relevant bit from the standard ([C89](http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf), section 7.20.3):


 > The pointer returned if the allocation succeeds is
 > suitably aligned so that it may be assigned to a pointer
 > to any type of object and then used to access such an
 > object or an array of such objects in the space allocated

In other words, the compiler/library has to ensure that the pointer that `malloc` returns is aligned to whatever alignment requirements the current platform has.  If your platform requires 32-bit I/O to be aligned to 4-byte boundaries, then `malloc` is going to give you a pointer that's aligned to a 4-byte boundary.  The pointer has to work with "any type" of object (since you can't pass type information to `malloc`), so that means it will be aligned to whatever the strictest boundary for your platform is.  In a lot of cases this corresponds to the word size of the machine.

In your specific case, you only saw the problem when `N` was a multiple of 8.  Most likely, your platform's alignment rules required `malloc` to return pointers aligned to 8-byte boundaries.  When your allocation wasn't a multiple of 8 bytes, the `size % 8` bytes of space between the end of your buffer and the next 8-byte boundary were unused.  You could write into these bytes because there was no way for `malloc` to allocate them for someone else without generating a pointer that didn't meet the requirement above.  When `N` is indeed a multiple of 8, then the very next byte after the array is allocatable, and writing into it risks overwriting someone else's memory.  An interesting side effect is that code that appears to work on your machine might not work on a hardware platform that has different alignment requirements.