prefer "!=" when checking read_in_full() result

Comparing the result of read_in_full() using less-than is potentially dangerous, as a negative return value may be converted to an unsigned type and be considered a success. This is discussed further in 561598cfcf (read_pack_header: handle signed/unsigned comparison in read result, 2017-09-13). Each of these instances is actually fine in practice: - in get-tar-commit-id, the HEADERSIZE macro expands to a signed integer. If it were switched to an unsigned type (e.g., a size_t), then it would be a bug. - the other two callers check for a short read only after handling a negative return separately. This is a fine practice, but we'd prefer to model "!=" as a general rule. So all of these cases can be considered cleanups and not actual bugfixes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Jeff King committed Sep 27, 2017 at 02:00 UTC 61d36330b422237b6be9581cdbade07782ab61a8
3 files changed +3 -3
builtin/get-tar-commit-id.c
+1 -1
@@ -26,7 +26,7 @@ int cmd_get_tar_commit_id(int argc, const char **argv, const char *prefix)
26 usage(builtin_get_tar_commit_id_usage);
27
28 n = read_in_full(0, buffer, HEADERSIZE);
29 - if (n < HEADERSIZE)
29 + if (n != HEADERSIZE)
30 die("git get-tar-commit-id: read error");
31 if (header->typeflag[0] != 'g')
32 return 1;
csum-file.c
+1 -1
@@ -19,7 +19,7 @@ static void flush(struct sha1file *f, const void *buf, unsigned int count)
19
20 if (ret < 0)
21 die_errno("%s: sha1 file read error", f->name);
22 - if (ret < count)
22 + if (ret != count)
23 die("%s: sha1 file truncated", f->name);
24 if (memcmp(buf, check_buffer, count))
25 die("sha1 file '%s' validation error", f->name);
pkt-line.c
+1 -1
@@ -258,7 +258,7 @@ static int get_packet_data(int fd, char **src_buf, size_t *src_size,
258 }
259
260 /* And complain if we didn't get enough bytes to satisfy the read. */
261 - if (ret < size) {
261 + if (ret != size) {
262 if (options & PACKET_READ_GENTLE_ON_EOF)
263 return -1;
264