In case of some glib-2.0 linker error ,
make examples
can't link with glib2.0, in this case -lglib-2.0 to after includes and move to last will solve the issues.
Do not define _XOPEN_SOURCE for OS X
redis@bb1747b appears to have introduced a build regression for OS X (and possibly elsewhere, I've only tested on a local Mac environment) — in master right now `make` reliably fails on OS X as reported in redis#431.
There looks to be another PR to fix the issue in redis#433.
This PR here simply returns to the previous behavior on OS X in a minimally-invasive way. There are of course a few different ways to do this with the directives; feel free to do something different, I just care that master can build on OS X 🙇
this issue is very significant, because not allow the proper execution of the "function redisCommandArgv". The server returns "invalid bulk length".
Thanks!
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.
fix: Rename DEBUG to DEBUG_FLAGS
This avoids issues with environments where DEBUG is set to an arbitrary
value to force debug mode in other tools.
BREAKING CHANGE: This breaks builds that explicitely set `DEBUG` to
some value (even the empty value).
To get back the old behaviour change the `DEBUG_FLAGS`
variable now.
Cloes #381
This avoids issues with environments where DEBUG is set to an arbitrary
value to force debug mode in other tools.
BREAKING CHANGE: This breaks builds that explicitely set `DEBUG` to
some value (even the empty value).
To get back the old behaviour change the `DEBUG_FLAGS`
variable now.
Fix potential race in 'invalid timeout' tests
It's possible for the call to connect() to succeed on the very first try, in which case the logic for checking for invalid timeout fields is never executed. When this happens, the tests fail because they expect a REDIS_ERR_IO but no such failure has occurred.
Tests aside, this is a potential source of irritating and hard-to-find intermittent bugs.
This patch forces the validation to occur early so that we get predictable behavior whenever an invalid timeout is specified.
Update read.c
static char *seekNewline(char *s, size_t len) :
this function can not parse the string,such as "hello world\r". the case that the last char is '\r'.
fix: Remove backwards compatibility macro's
Closes#296
BREAKING CHANGE: This removes the redisReplyReader* functions, which are
already replaced by redisReader* functions.
It renames `redisReplyReaderSetPrivdata`,
`redisReplyReaderGetObject` and `redisReplyReaderGetError`
to `redisReaderSetPrivdata`, `redisReaderGetObject`
and `redisReaderGetError`.
fmacros.h: Fix warning when compiled with -Wundef
When compiling with the flag `-Wundef` the following warning is emitted:
```
[ 40%] Building C object CMakeFiles/hiredis-STATIC.dir/read.c.o
In file included from /data/files/users/jerry/github/hiredis/read.c:33:0:
/data/files/users/jerry/github/hiredis/fmacros.h:17:5: warning: "__APPLE__" is not defined [-Wundef]
#if __APPLE__ && __MACH__
^
In file included from /usr/include/string.h:25:0,
from /data/files/users/jerry/github/hiredis/read.c:34:
```
Closes#296
BREAKING CHANGE: This removes the redisReplyReader* functions, which are
already replaced by redisReader* functions.
It renames `redisReplyReaderSetPrivdata`,
`redisReplyReaderGetObject` and `redisReplyReaderGetError`
to `redisReaderSetPrivdata`, `redisReaderGetObject`
and `redisReaderGetError`.
Prevent buffer overflow when formatting the error
strncat might copy n+1 bytes (n bytes from the source plus a terminating nul byte).
Also strncat appends after the first found nul byte. But all we pass is
a buffer we might not have zeroed out already.
Closes#380
test.c: Fix shadowed name with typedef when compiling with -Wshadow
Fixes:
```
/data/files/users/jerry/github/hiredis/test.c: In function 'test_free_null':
/data/files/users/jerry/github/hiredis/test.c:331:11: warning: declaration of 'redisContext' shadows a global declaration [-Wshadow]
void *redisContext = NULL;
^
In file included from /data/files/users/jerry/github/hiredis/test.c:13:0:
/data/files/users/jerry/github/hiredis/hiredis.h:161:3: note: shadowed declaration is here
} redisContext;
^
```
strncat might copy n+1 bytes (n bytes from the source plus a terminating nul byte).
Also strncat appends after the first found nul byte. But all we pass is
a buffer we might not have zeroed out already.
Closes#380
It's possible for the call to connect() to succeed on the very first
try, in which case the logic for checking for invalid timeout fields is
never executed. When this happens, the tests fail because they expect a
REDIS_ERR_IO but no such failure has occurred.
Tests aside, this is a potential source of irritating and hard-to-find
intermittent bugs.
This patch forces the validation to occur early so that we get
predictable behavior whenever an invalid timeout is specified.
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.
