search for: unaligned_int32_t

...uffer into a properly aligned variable and pass that, or use a carefully under-aligned type. In Clang you can create a specifically under-aligned integer type, and as long as all *accesses* go through that type it should work. So something like this: typedef int32_t __attribute__((aligned(1))) unaligned_int32_t; [...] int32_t doSomethingWithInts(unaligned_int32_t *Ints) { return Ints[0] + Ints[1]; } But that's obviously a non-standard extension (GCC supports it, and I believe MSVC has a similar but incompatible concept). It's also really easy to mess that up, the attribute gets...

Hi Tim, Thanks for the explanation. The above code snippets is actually extracted by bugpoint from MultiSource/Applications/ALAC/encode/alacconvert-encode.test. I get a different result if I cast the pointer to int and mask away the lower two bits and cast the int back to pointer. While casting pointer to int and back to pointer do not cause any problem. Thanks Hongbin On Fri, Dec 16, 2016 at

...easonable to copy the buffer just to satisfy my function. So how can I make this function handle unaligned buffers? The type of the argument itself means that being passed an unaligned buffer has undefined behavior. Now, I can change that parameter to use an unaligned typedef: typedef int32_t unaligned_int32_t __attribute__((aligned(1))); void processBuffer(const unaligned_int32_t *buffer, size_t length) { ... } But this has severe problems. First off, this is a GCC/Clang extension; a lot of programmers feel uncomfortable adopting that, especially to fix a problem that's in principle common...

...o satisfy > my function. > > So how can I make this function handle unaligned buffers? The type of the > argument itself means that being passed an unaligned buffer has undefined > behavior. Now, I can change that parameter to use an unaligned typedef: > > typedef int32_t unaligned_int32_t __attribute__((aligned(1))); > void processBuffer(const unaligned_int32_t *buffer, size_t length) { > ... > } > > But this has severe problems. First off, this is a GCC/Clang extension; a lot > of programmers feel uncomfortable adopting that, especially to fix a problem...