wrapper: reject count > SSIZE_MAX in read_in_full/write_in_full

Both functions accumulate bytes transferred in a ssize_t total
variable, but accept a size_t count parameter. When count exceeds
SSIZE_MAX, total overflows after processing SSIZE_MAX bytes,
producing a negative return value that callers interpret as an
error (or worse, a small positive value after further wrapping).

In practice, git never passes such large counts because file
sizes and buffer allocations are bounded well below SSIZE_MAX on
all target platforms. The POSIX specification for read() and
write() also limits single operations to SSIZE_MAX bytes, and
git's xread/xwrite wrappers further clamp to MAX_IO_SIZE. But
the accumulation in the _in_full wrappers means that even with
per-call clamping, total can exceed SSIZE_MAX when count does.

Reject count > SSIZE_MAX upfront with EINVAL rather than
silently producing wrong return values. This matches the POSIX
convention where read/write return EINVAL for invalid arguments.

Pointed out by Coverity.

Assisted-by: Claude Opus 4.6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Author: dscho

wrapper.c

@@ -288,6 +288,11 @@ ssize_t read_in_full(int fd, void *buf, size_t count)
 	char *p = buf;
 	ssize_t total = 0;
 
+	if (count > SSIZE_MAX) {
+		errno = EINVAL;
+		return -1;
+	}
+
 	while (count > 0) {
 		ssize_t loaded = xread(fd, p, count);
 		if (loaded < 0)
@@ -307,6 +312,11 @@ ssize_t write_in_full(int fd, const void *buf, size_t count)
 	const char *p = buf;
 	ssize_t total = 0;
 
+	if (count > SSIZE_MAX) {
+		errno = EINVAL;
+		return -1;
+	}
+
 	while (count > 0) {
 		ssize_t written = xwrite(fd, p, count);
 		if (written < 0)