This makes createArray consistent with createString, which also takes
size_t. Bounds-check and unit tests are updated to allow up to
min(SIZE_MAX,LLONG_MAX).
Changelog is updated to mention this API break.
Signed-off-by: Justin Brewer <jzb0012@auburn.edu>
processMultiBulkItem truncates the value read from readLongLong,
resulting in a corrupted state when the next item is read.
createArray takes an int, so bound to INT_MAX.
Inspection showed that processBulkItem had the same truncation issue.
createString takes size_t, so bound to SIZE_MAX. This only has an
effect on 32-bit platforms.
A strict lower bound is also added, since negative lengths other
than -1 are invalid according to RESP.
Signed-off-by: Justin Brewer <jzb0012@auburn.edu>
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.
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.
Originally implemented by @abedra as part of #306.
In case a write or read times out, we force an error state, because we
can't guarantuee that the next read will get the right data.
Instead we need to reconnect to have a clean-state connection, which is
now easily possible with this method.
Suggested at
https://github.com/redis/hiredis/issues/294#issuecomment-69153074
This change also makes the test stop hanging for 10 to 30 seconds
waiting for the resolver to timeout. Now the resolver immediately
sees the hostname is bad and returns error without waiting for timeout.
Closes#154
This commit properly sets the error value inside of
redisContextWaitReady when an invalid sec or usec value is provided.
Tests for each case are provided to demonstrate that the issue is
properly fixed and to avoid regression.
Signed-off-by: Aaron Bedra <aaron@aaronbedra.com>
This reverts commit 77540aa316. The change
in buffer strategy is too large to put in a minor release. It is put in
a separate branch in the meantime, so it can be refined and released
together with a minor version bump.
This is done by only truncating the read buffer once a full reply has
been read. The buffer is no longer truncated halfway through reading a
reply. In addition: pass offset/length of protocol and content via the
read tasks.
When there is an I/O error, errno should be used to find out what is
wrong. In other cases, errno cannot be used. So, use an explicit type in
Hiredis to define the different error scenarios that can occur.
Rather, use the return value REDIS_OK and REDIS_ERR to designate if
calling a function has a successful outcome. When there was an error in
performing the call the error field will be set inside the reader or the
context.
The context supports both blocking and non-blocking connections. All
read and write events are not handled by hiredis, but hiredis exposes an
API for buffered reading/writing to Redis.
Allows libraries to wrap the reply parsing code and build the reply in a
streaming fashion. Reply objects can immediately be initialized to the
required type without having to convert an intermediary format.
