Fix segfault when memmoving with negative/enormous n

[jnpkrn]

I observed a segmentation fault caused by trying to memmove by -15,
which makes 18446744073709551601 on my 64-bit platform after an argument
type promotion (from int into size_t). In my case, this was connected
with filling up disk during the test facilitated by check, hence I derive
that the main issue was that not enough bytes for particular type of
message was actually read (and previously written, for that matter) and
because of this incompleteness, get_result happily consumed more bytes
than was read.

Additional debugging info at the point of segfault (src/check_pack.c):

468│         /* Move remaining data in buffer to the beginning */
469├>        memmove(buf, buf + n, nparse);
470│         /* If EOF has not been seen */
471│         if(nread > 0)

(gdb) p nparse
$1 = -15
(gdb) p n
$2 = 23
(gdb) p nread
$3 = 0

[jnpkrn]

Note that

get_result happily consumed more bytes than was read

is just as serious, however I don't feel competent to do such a complex
refactoring, i.e., propagation of the number of bytes that can still be
consumed before reading pass the defined content within the buffer,
on my own.

[brarcher]

Jenkins: ok to test

[brarcher]

Looking at the code, I agree that get_result should not attempt to consume more than is available. Probably there is a more graceful way to handle such a failure. Though, likely all it would do is attempt to abort because the framework hit a condition it is unable to handle.

Thanks for the change. If you could, may you also submit a pull request adding yourself to the AUTHORS file if you are not already listed?

[jnpkrn]

Done: PR #22.