From: Jonathan Nieder <jrnieder@gmail.com>
To: David Barr <davidbarr@google.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 3/7] vcs-svn: fix signedness warnings
Date: Thu, 24 May 2012 09:48:47 -0500 [thread overview]
Message-ID: <20120524144847.GC3732@burratino> (raw)
In-Reply-To: <1337868259-45626-4-git-send-email-davidbarr@google.com>
David Barr wrote:
> --- a/vcs-svn/fast_export.c
> +++ b/vcs-svn/fast_export.c
> @@ -259,7 +259,7 @@ static int parse_ls_response(const char *response, uint32_t *mode,
> }
>
> /* Mode. */
> - if (response_end - response < strlen("100644") ||
> + if (response_end - response < (off_t) strlen("100644") ||
I wish the static analyzer could notice that "response_end - response"
is always nonnegative and stop worrying. If we want to appease it,
I guess I'd mildly prefer something like
if (response_end - response < (signed) strlen("100644") ||
which expresses the intent more directly.
[...]
> --- a/vcs-svn/line_buffer.c
> +++ b/vcs-svn/line_buffer.c
> @@ -91,8 +91,7 @@ char *buffer_read_line(struct line_buffer *buf)
> return buf->line_buffer;
> }
>
> -size_t buffer_read_binary(struct line_buffer *buf,
> - struct strbuf *sb, size_t size)
> +off_t buffer_read_binary(struct line_buffer *buf, struct strbuf *sb, off_t size)
> {
> return strbuf_fread(sb, size, buf->infile);
> }
On systems with larger off_t than size_t (think "typical 32-bit PC,
since file offsets tend to be 64 bits"), this silently throws away
bits. I think the cure is worse than the disease.
[...]
> --- a/vcs-svn/sliding_window.c
> +++ b/vcs-svn/sliding_window.c
> @@ -43,11 +43,11 @@ static int check_offset_overflow(off_t offset, uintmax_t len)
> return 0;
> }
>
> -int move_window(struct sliding_view *view, off_t off, size_t width)
> +int move_window(struct sliding_view *view, off_t off, off_t width)
> {
Likewise. I'd rather the caller know that the window has to fit in an
address space which can be smaller than the maximum file size.
Is this to avoid having two different functions that parse a
variable-length integer, or is there some other reason?
Hope that helps,
Jonathan
next prev parent reply other threads:[~2012-05-24 14:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-24 14:04 [PATCH 0/7] vcs-svn: housekeeping David Barr
2012-05-24 14:04 ` [PATCH 1/7] vcs-svn: prefer constcmp to prefixcmp David Barr
2012-05-24 14:04 ` [PATCH 2/7] vcs-svn: prefer strstr over memmem David Barr
2012-05-24 14:04 ` [PATCH 3/7] vcs-svn: fix signedness warnings David Barr
2012-05-24 14:48 ` Jonathan Nieder [this message]
2012-05-31 13:14 ` David Michael Barr
2012-05-24 14:04 ` [PATCH 4/7] vcs-svn: drop no-op reset methods David Barr
2012-05-24 14:04 ` [PATCH 5/7] vcs-svn: fix cppcheck warning David Barr
2012-05-24 14:20 ` Jonathan Nieder
2012-05-31 11:17 ` David Michael Barr
2012-05-24 14:04 ` [PATCH 6/7] vcs-svn: fix clang-analyzer error David Barr
2012-05-24 14:04 ` [PATCH 7/7] vcs-svn: fix clang-analyzer warning David Barr
2012-05-24 14:33 ` Jonathan Nieder
2012-05-31 11:34 ` David Michael Barr
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=20120524144847.GC3732@burratino \
--to=jrnieder@gmail.com \
--cc=davidbarr@google.com \
--cc=git@vger.kernel.org \
/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 NNTP newsgroup(s).