summaryrefslogtreecommitdiff
path: root/fmacros.h
AgeCommit message (Collapse)Author
2018-04-28Strip down fmacros.hJustin Brewer
strerror_r and addrinfo require _POSIX_C_SOURCE >= 200112L, which is implied by _XOPEN_SOURCE >= 600. With the removal of AF_LOCAL usage, the only non-standard features being used are the TCP_KEEP* socket flags. _DARWIN_C_SOURCE is required to expose TCP_KEEPALIVE. Fall back to using _XOPEN_SOURCE 600 for all platforms, and additionally define _DARWIN_C_SOURCE for Darwin. Signed-off-by: Justin Brewer <jzb0012@auburn.edu>
2018-01-06Make it compile on IBM AIX systemsJan-Erik Rediger
Closes #422
2018-01-05Make XOPEN_SOURCE definition explicit per architectureJan-Erik Rediger
Fixes #441
2017-05-17Fix compilation on FreeBSD 10.3 with default compilereldarko
2016-06-19Do not define _XOPEN_SOURCE for OS XTed Nyman
Resolves failed `make` on OS X.
2016-05-12Auto merge of #378 - thomaslee:tom_fix_kfreebsd, r=badboynot-a-robot
Fix strerror_r on some esoteric platforms Defining _XOPEN_SOURCE=1 causes strange behavior on Debian kfreebsd archs -- i.e. the GNU userspace with FreeBSD kernel -- when _GNU_SOURCE is not defined (the default). 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.
2016-04-20Auto merge of #414 - redis:fix-cygwin, r=badboynot-a-robot
Fix cygwin
2016-04-20Add CI for Windowsowent
- fix macro problem in mingw-gcc - fix typedef in cygwin
2016-04-17fmacros.h: Fix warning when compiled with -WundefJerry Jacobs
2015-11-18Fix strerror_r on some esoteric platformsTom Lee
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.
2015-01-06Silence _BSD_SOURCE warningsMatt Stancliff
glibc 2.20 requires _DEFAULT_SOURCE and doesn't like _BSD_SOURCE alone Also see: - https://github.com/antirez/redis/pull/2189 - https://sourceware.org/glibc/wiki/Release/2.20#Deprecation_of__BSD_SOURCE_and__SVID_SOURCE_feature_macros Thanks to badboy for pointing out the problem at https://github.com/redis/hiredis/issues/288#issuecomment-68849454
2014-04-09Define _XOPEN_SOURCE for NetBSDPatrick TJ McPhee
This is backported from https://github.com/antirez/redis/commit/289942b6259670fe3dcfaffdd0135c27f14c61c0
2013-05-01Make redisKeepAlive work on OSXPieter Noordhuis
2011-06-187th revision is not necessaryPieter Noordhuis
2011-06-18Define _POSIX_C_SOURCE for SolarisPieter Noordhuis
2011-03-29Update fmacros.hPieter Noordhuis
2010-05-18hiredis was extracted from redis-tools, reverted to standard malloc/free, ↵antirez
ported to the new protocol, and started as a stand alone project in order to support the need of a C client in the Redis community
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-20 11:41:00 +0000