On 01/07/2011 08:13 PM, Andy Green wrote: > On 01/07/11 18:45, Somebody in the thread at some point said: > >>> With this issue, a correct structure in a typedef or a struct with >>> correct alignment padding turns to crap because the structure pointed to >>> is not on a u32 boundary for example. >> >> I see. But shouldn't the compiler be taking care of that? -malign? > > For most code the compiler or malloc is ultimately always making the > pointer and takes care about its alignment so you never see such symptoms. > > However take for example structures that are coming into a buffer as > part of a byte stream, it is uncontrolled how many bytes have come in, > but you know there is a struct in the buffer n bytes from the start of > your buffer. Like --> > > struct mystruct *p = (struct mystruct *)&buffer[n]; > > On x86 this code is always OK, although it may run faster or slower > depending on alignment. Yes, but in C code this is always a bug, and should always be fixed. Even on x86 it may not always generate code that does what you want: gcc is perfectly entitled to assume that an unaligned pointer is never used. And even now, x86 has a big performance hit for word accesses that straddle a cache line boundary. Andrew. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
