Don't try to read zero bytes in `_bulk_reply()`

While investigating transactions blocking indefinitely (or taking minutes to return) I
realized that we only rturn NULL in _bulk_reply() if we detect there are less than
zero bytes to read, but continue if there are non-zero (including zero) bytes to read.

Since the length value passed to fgets() is padded by one (+1), we perenially block
for a byte that just does not exist in the stream in that case.

This trivial patch fixes that.

Signed-off-by: Tim Post <tpost@ezp.net>
Merge pull request #13 from tinkertim/master

Don't try to read zero bytes in `_bulk_reply()`
Updated README
Don't truncate the response if the bulk reply has multiple \n\r's. Fixed #15.
Added manual implementation for Redis::info()
Used better variable names in the new info method.
Added an extra check when exploding the return info string to take comments into account. These comments are found in Redis > 2.6.0
Fixed typo in README.md (missing "'" in hmset example)
Merge pull request #16 from tinkertim/master

Fix minor typo in README.md
Added tests for issue #18.
Fixed handling for commands with 3+ arguments.
Updated to properly handle array arguments.

Signed-off-by: Daniel Hunsaker <danhunsaker@gmail.com>
Merge pull request #20 from danhunsaker/develop

Fixed handling for commands with 3+ arguments.
Cleaned up tests and started working on more granular test suite.
Merged in develop branch.
Added tests for associative arrays.
Added static function to determine whether we're deadling with an associative array or not.
Expanded _encode_request to take into account lists.
Added Dan to thank you section. Fixed #21.
It's 2013 now.