Jeff King <peff@xxxxxxxx> writes:
> diff --git a/csum-file.c b/csum-file.c
> index a172199e44..2adae04073 100644
> --- a/csum-file.c
> +++ b/csum-file.c
> @@ -19,7 +19,7 @@ static void flush(struct sha1file *f, const void *buf, unsigned int count)
>
> if (ret < 0)
> die_errno("%s: sha1 file read error", f->name);
> - if (ret < count)
> + if (ret != count)
> die("%s: sha1 file truncated", f->name);
I personally find that this "ret < count" that comes after checking
if ret is negative expresses what it is checking in a more natural
way than "ret must be exactly count".
It is not a big deal, as either one needs to be read with an
understanding that read_in_full() would read at most "count" bytes
to see if the right condition is being checked to declare
"truncated" anyway. But I somehow find
ret = read up to count
if (ret < 0)
read failed
if (ret < count)
we failed to read as much as expected
a bit more natural.
> diff --git a/pkt-line.c b/pkt-line.c
> index 647bbd3bce..93ea311443 100644
> --- a/pkt-line.c
> +++ b/pkt-line.c
> @@ -258,7 +258,7 @@ static int get_packet_data(int fd, char **src_buf, size_t *src_size,
> }
>
> /* And complain if we didn't get enough bytes to satisfy the read. */
> - if (ret < size) {
> + if (ret != size) {
> if (options & PACKET_READ_GENTLE_ON_EOF)
> return -1;
Likewise, even though it is harder to see that this follows another
explicit check for "ret < 0".
Thanks.
