From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] difftool: avoid strcpy
Date: Thu, 30 Mar 2017 15:19:40 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1703301517260.4068@virtualbox> (raw)
In-Reply-To: <20170330103550.vpjrurqho4oz3caa@sigill.intra.peff.net>
Hi Peff,
On Thu, 30 Mar 2017, Jeff King wrote:
> In order to checkout files, difftool reads "diff --raw"
> output and feeds the names to checkout_entry(). That
> function requires us to have a "struct cache_entry". And
> because that struct uses a FLEX_ARRAY for the name field, we
> have to actually copy in our new name.
>
> The current code allocates a single re-usable cache_entry
> that can hold a name up to PATH_MAX, and then copies
> filenames into it using strcpy(). But there's no guarantee
> that incoming names are smaller than PATH_MAX. They've come
> from "diff --raw" output which might be diffing between two
> trees (and hence we'd be subject to the PATH_MAX of some
> other system, or even none at all if they were created
> directly via "update-index").
>
> We can fix this by using make_cache_entry() to create a
> correctly-sized cache_entry for each name. This incurs an
> extra allocation per file, but this is negligible compared
> to actually writing out the file contents.
>
> To make this simpler, we can push this procedure into a new
> helper function. Note that we can also get rid of the "len"
> variables for src_path and dst_path (and in fact we must, as
> the compiler complains that they are unused).
Oh woops. Thanks for noticing and for patching it right away!
> I tested this with:
>
> git init
> sha1=$(echo whatever | git hash-object -w --stdin)
> git update-index --add --cacheinfo \
> 100644 $sha1 $(perl -e 'print join("/", 1..2048)')
> git difftool -d HEAD
>
> It fails anyway, of course, because we can't check out a filename of
> that length, but not until after it has overflowed the buffer.
>
> I'm not sure if we'd want that in the test suite or not, since the
> outcome is unpredictable.
I'd leave it out. There is really no reliable way to test this.
> builtin/difftool.c | 31 +++++++++++++++----------------
> 1 file changed, 15 insertions(+), 16 deletions(-)
Nice! I would have thought that it adds to the total number of lines.
Instead, it removes many fiddly `*_len = *` assignments and makes the code
more robust.
ACK!
Dscho
prev parent reply other threads:[~2017-03-30 13:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-30 10:35 [PATCH] difftool: avoid strcpy Jeff King
2017-03-30 13:19 ` Johannes Schindelin [this message]
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=alpine.DEB.2.20.1703301517260.4068@virtualbox \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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