Hi Max, Hi Edwards, hi everyone i ve bumped into some strange behaviour again lately during some code cleanup. I can work around it, but i wondered if other before me ran into this and wether this is UB, a compiler bug or something ecos specific.
My Compiler: Im compiling under ubuntu 14.04 for the MPC5668x powerpc architecture with ppc-eabi-gcc 4.8.2 toolchain (if i found the correct compiler there) . The problem occurs when casting pointers to a smaller size; Example: cyg_uint32 testValue = 0x12345678; cyg_uint8 *ptrToLowestByte; cyg_uint32 *ptrToWholeValue; ptrToLowestByte = (cyg_uint8 *) (&testValue); ptrToWholeValue = (cyg_uint32 *) ptrToLowestByte; I can work with the ptrToTheWholeValue as long i do not use any binary operations with a diffrent size For example cyg_uint32 container32 = ((*ptrToWholeValue) & 0xFF00 0000) will return valid Value into the corresponding 32uint container; cyg_uint8 container8 = (cyg_uint8) ((ptrToWholeValue & 0xFF00 0000 ) >> 24); However will not. My assumption is that the endianess of the dereferenced Value is wrong, a cast pointer does no longer point to the lowest byte, but to the highest instead. I worked around it by not using bitops that shift into a diffrently sized variable from a pointer. If requested i could upload some dissasembly. I also experienced some problems using memcpy and strncpy, when using casted down uint8* ptr to uint8 arrays - where the values to copy where copyied in at a offset off the original ptrs data type (uint32*). This all may be perfectly normal behaviour and i m just lacking experience- in that case i would be very glad for any explenation. Anybody experienced something similar? There seem to be some todos regarding assembly binary operations in the vle.h still open. Should i report this to the gnu or will i get trampled by a stampede? Regards Pica -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
