------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1049 --- Comment #30 from Craig Silverstein <[email protected]> 2011-11-16 20:09:37 --- This construct is not legal in C, as far as I understand it. It is an aliasing violation to store data in one field of a union and read it from another. The compiler can do crazy things that would make you sad. There's a series of macros that are the 'blessed' way of figuring out endianness. Here's what I do in one project I have: // This is all to figure out endian-ness and byte-swapping on various systems #if defined(HAVE_ENDIAN_H) #include <endian.h> // for the __BYTE_ORDER use below #elif defined(HAVE_SYS_ENDIAN_H) #include <sys/endian.h> // location on FreeBSD #elif defined(HAVE_MACHINE_ENDIAN_H) #include <machine/endian.h> // location on OS X #endif #if defined(HAVE_SYS_BYTEORDER_H) #include <sys/byteorder.h> // BSWAP_32 on Solaris 10 #endif #ifdef HAVE_SYS_ISA_DEFS_H #include <sys/isa_defs.h> // _BIG_ENDIAN/_LITTLE_ENDIAN on Solaris 10 #endif In linux (glibc), the macro __BYTE_ORDER is set to either __LITTLE_ENDIAN or __BIG_ENDIAN. Other systems do something similar. I can't guarantee all systems have a macro for this, though. craig -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
