On Thu, Oct 30, 2014 at 3:28 AM, awt <[email protected]> wrote: > Thanks for your reply Dan. In my case, I am explicitly creating an array > of bytes and if I have enough space in the array, why should there be an > issue with copying an integer to the array even if the memory address is > not aligned? For e.g., I have an array of 10 bytes, I copy one byte to the > array and after that, copy an int (4 bytes). I would expect Emscripten to > allow me to do the copying as long as I have enough capacity in the array. >
In C, that's undefined behavior. It happens to work on some platforms, but if you want to write four bytes to an unaligned address, use memcpy. What is more puzzling is that this works on my Mac machine but just not on > Emscripten. Is there a reason for this difference in behaviour? I could use > memcpy but just want to spend a little more time to understand this issue. > On x86, reading and writing unaligned pointers generally works. On ARM, MIPS, PowerPC, and Emscripten, it doesn't work. :) Use memcpy in this case and your problems will be solved. > > > On Tuesday, October 28, 2014 10:58:30 PM UTC+8, Dan Gohman wrote: >> >> Hello, >> >> Yes, an address is "aligned" when the numeric value of the address is a >> multiple of some value. In your case, the code is storing an int, which >> requires an alignment of 4 on most platforms. Most of the time, the >> compiler and library will automatically allocate things at suitable >> addresses for you so you don't have to worry about alignment. But, when you >> take an arbitrary char* value and cast it to int*, the C language says that >> it's your responsibility to make sure the pointer value is a multiple of >> the required alignment value (4, here). >> >> Loading or storing with an address that is not suitably aligned for the >> type of the access triggers what the C language calls "undefined behavior". >> It may do what you expect sometimes, but C compilers sometimes find clever >> ways of optimizing using the assumption that all accesses are through >> aligned pointers. When they do this, it can cause the program to misbehave >> on unaligned pointers, so it's wise to avoid giving them the chance to >> cause trouble. It's the same situation under Emscripten, except that >> Emscripten *always* does something clever. >> >> The typical way to fix this bug in your code is to use memcpy, since >> memcpy has no alignment requirement: >> >> memcpy(_bos, &val, sizeof(int)); >> >> Dan >> >> ----- Original Message ----- >> > Hi, >> > >> > I was trying to assign an integer value to an array of unsigned char >> when I >> > encountered an alignment error on SAFE_HEAP. The code is as follows: >> > >> > *((int*)(_bos) = val; >> > >> > where val is of type integer and _bos is of type unsigned char*. I am >> just >> > curious as to why there is an alignment error when _bos is 1 byte in >> length >> > and an integer is 4 bytes. Is it because the memory allocated to _bos >> is >> > not big enough or not in multiples of 4? >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "emscripten-discuss" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to [email protected]. >> > For more options, visit https://groups.google.com/d/optout. >> > >> > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Chad Austin Technical Director, IMVU http://engineering.imvu.com <http://www.imvu.com/members/Chad/> http://chadaustin.me -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
