#ifndef __HIREDIS_FMACRO_H
#define __HIREDIS_FMACRO_H

#if defined(__linux__)
#define _BSD_SOURCE
#define _DEFAULT_SOURCE
#endif

#if defined(__sun__)
#define _POSIX_C_SOURCE 200112L
#else
#define _XOPEN_SOURCE 600
#endif

#if __APPLE__ && __MACH__
#define _OSX
#endif

#endif

#ifndef __HIREDIS_FMACRO_H
#define __HIREDIS_FMACRO_H

#if defined(__linux__)
#define _BSD_SOURCE
#define _DEFAULT_SOURCE
#endif

#if defined(__sun__)
#define _POSIX_C_SOURCE 200112L
#elif defined(__linux__) || defined(__OpenBSD__) || defined(__NetBSD__)
#define _XOPEN_SOURCE 600
#else
#define _XOPEN_SOURCE
#endif

#if __APPLE__ && __MACH__
#define _OSX
#endif

#endif

--- 
+++ 
@@ -8,10 +8,8 @@
 
 #if defined(__sun__)
 #define _POSIX_C_SOURCE 200112L
-#elif defined(__linux__) || defined(__OpenBSD__) || defined(__NetBSD__)
+#else
 #define _XOPEN_SOURCE 600
-#else
-#define _XOPEN_SOURCE
 #endif
 
 #if __APPLE__ && __MACH__
Fix strerror_r on some esoteric platforms

Defining _XOPEN_SOURCE=1 causes strange behavior on Debian kfreebsd
archs (i.e. GNU userspace with FreeBSD kernel) when _GNU_SOURCE is not
defined.

Not sure I fully understand the bizarre semantics, but it seems to
use the XSI-compliant interface
(int strerror_r(int, char*, size_t)) but the GNU implementation
(char *strerror_r(int, char*, size_t)) such that strerror_r returns
32-bits of a 64-bit char * on x86_64 kfreebsd. We would expect
strerror_r to return zero when using the XSI-compliant strerror_r
implementation or a 64-bit char* when using the GNU version. Instead,
we get something in between!

Unless I'm missing something, being more explicit about what version
of _XOPEN_SOURCE we want seems to be the prudent thing to do here --
and if folks want the GNU implementation of strerror_r for some reason
they can always -D_GNU_SOURCE explicitly.
