From: Jeff King <peff@peff.net>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: Tuomas Ahola <taahol@utu.fi>, git@vger.kernel.org
Subject: Re: [PATCH] bulk-checkin: fix sign compare warnings
Date: Sun, 23 Mar 2025 22:53:00 -0400 [thread overview]
Message-ID: <20250324025300.GA690113@coredump.intra.peff.net> (raw)
In-Reply-To: <CAOLa=ZRN5m0bccMdabUYwNJLg4HX6jcOe3PN-aBTHXBOuM71hw@mail.gmail.com>
On Fri, Mar 21, 2025 at 05:08:06PM -0400, Karthik Nayak wrote:
> > @@ -192,7 +188,7 @@ static int stream_blob_to_pack(struct bulk_checkin_packfile *state,
> > offset += rsize;
> > if (*already_hashed_to < offset) {
> > size_t hsize = offset - *already_hashed_to;
> > - if (rsize < hsize)
> > + if ((size_t)rsize < hsize)
>
> Something I found peculiar here is that `rsize` is of type ssize_t'.
> But it only seems to store a positive value.
I assumed it was ssize_t because it would hold the result of a read
call. But it doesn't! We put that into the "read_result" variable.
So it could just be a size_t in the first place. And indeed it is better
as one, because we assign from "size", which is itself a size_t. We do
not yet warn about type mismatches outside of comparisons, but really it
is equally bad.
However, if you switch it, then we get a different -Wsign-compare
problem: we compare "rsize" and "read_result". So you still have to
cast, but at a different spot.
If we are doing this a lot (and really this conversion is necessary any
time you look at the outcome of a read call), I do still wonder if we
should have a helper like:
static inline int safe_scast(ssize_t ret, size_t *out)
{
if (ret < 0)
return 0;
/* cast is safe because of check above */
*out = (size_t)ret;
return 1;
}
(yes, I know the name is lousy). That would allow something like this:
diff --git a/bulk-checkin.c b/bulk-checkin.c
index f6f79cb9e2..fbffc7c8d6 100644
--- a/bulk-checkin.c
+++ b/bulk-checkin.c
@@ -178,9 +178,10 @@ static int stream_blob_to_pack(struct bulk_checkin_packfile *state,
while (status != Z_STREAM_END) {
if (size && !s.avail_in) {
- ssize_t rsize = size < sizeof(ibuf) ? size : sizeof(ibuf);
- ssize_t read_result = read_in_full(fd, ibuf, rsize);
- if (read_result < 0)
+ size_t rsize = size < sizeof(ibuf) ? size : sizeof(ibuf);
+ size_t read_result;
+
+ if (!safe_scast(read_in_full(fd, ibuf, rsize), &read_result))
die_errno("failed to read from '%s'", path);
if (read_result != rsize)
die("failed to read %d bytes from '%s'",
Though it does kind of obscure the call to read_in_full(). You can use
two variables, like:
ssize_t read_result;
size_t bytes_read;
read_result = read_in_full(fd, ibuf, rsize);
if (!safe_scast(read_result, &bytes_read))
die_errno(...);
which is a bit more verbose but perhaps clearer.
This reminded me a bit of the issues we had with write_in_full() before,
where:
if (write_in_full(fd, buf, len) < len)
behaves unexpectedly because of integer conversions. There the solution
was to never check against "len", because write_in_full() either writes
everything or returns an error. So:
if (write_in_full(fd, buf, len) < 0)
is correct and sufficient.
But alas, we can't do the same here, because reading returns three
cases: error, a full read, or a partial read (maybe even EOF!). So we
really do need to record and compare the return value between what we
asked for and what we got.
-Peff
next prev parent reply other threads:[~2025-03-24 2:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-21 20:07 [PATCH] bulk-checkin: fix sign compare warnings Tuomas Ahola
2025-03-21 21:08 ` Karthik Nayak
2025-03-21 22:14 ` [PATCH v2] " Tuomas Ahola
2025-03-23 22:08 ` Junio C Hamano
2025-03-24 2:53 ` Jeff King [this message]
2025-03-24 19:48 ` [PATCH] " Karthik Nayak
2025-03-24 20:13 ` Jeff King
2025-03-24 21:47 ` [PATCH v3] " Tuomas Ahola
2025-03-24 23:46 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250324025300.GA690113@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=karthik.188@gmail.com \
--cc=taahol@utu.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).