Thanks Chad :) On Thursday, October 30, 2014 6:48:17 PM UTC+8, Chad Austin wrote: > > On Thu, Oct 30, 2014 at 3:28 AM, awt <[email protected] <javascript:>> > 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] <javascript:>. >> 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.
