On Sat, Nov 07, 2009 at 05:23:38PM +0100, Tobias Heer wrote: > > Am 07.11.2009 um 14:07 schrieb Diego Biurrun: > > >>+ */ > >>+#ifdef __APPLE__ > >>+ #ifndef __BYTE_ORDER > >>+ #define __BYTE_ORDER BYTE_ORDER > >>+ #endif > >>+ #ifndef __BIG_ENDIAN > >>+ #define __BIG_ENDIAN BIG_ENDIAN > >>+ #endif > >>+#endif > > > >General note: Checking #ifdefs like this does not yield to general > >portability and is very ugly overall. Compiler and system > >capabilities > >are subject to rather quick changes. What if the Apple compiler does > >support __BYTE_ORDER next year? > > If it supports __BYTE_ORDER next year, this code will stil work. This was meant more as a general remark. #ifdefs are generally not a good way to achieve portability. The worst thing is if you litter the code with #ifdef __FreeBSD__ ... #elif (defined __OPENBSD__) ... #elif (defined __CYGWIN__ || defined __MINGW32__) ... #elif (defined __GNUC__ || defined __APPLE__) ... #endif You get the idea. Little of this code will ever be (compile-)tested. Often the code within the #ifdefs is replacement for standard functions, sometimes even standard POSIX functions. Then the next operating system version comes along but you keep using your (buggy) reimplementation instead of using the well-tested system one. The way to go about this is to instead have #ifdef HAVE_WHATEVER_FEATURE <default code> #else <fallback code> #endif where HAVE_WHATEVER_FEATURE is autodetected by configure at compile-time. Thus no system features are hardcoded and you automatically pick up system features when they become available. This is the point I was trying to make, I guess it did not become clear at all from the few lines I wrote above :) Diego