From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/18] snprintf cleanups
Date: Tue, 28 Mar 2017 23:41:05 -0400 [thread overview]
Message-ID: <20170329034105.bfgh4tutgrmjp2lc@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqq60itc9pv.fsf@gitster.mtv.corp.google.com>
On Tue, Mar 28, 2017 at 03:33:48PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > It's a lot of patches, but hopefully they're all pretty straightforward
> > to read.
>
> Yes, quite a lot of changes. I didn't see anything questionable in
> there.
>
> As to the "patch-id" thing, I find the alternate one slightly easier
> to read. Also, exactly because this is not a performance critical
> codepath, it may be better if patch_id_add_string() filtered out
> whitespaces; that would allow the source to express things in more
> natural way, e.g.
>
> patch_id_addf(&ctx, "new file mode");
> patch_id_addf(&ctx, "%06o", p->two->mode);
> patch_id_addf(&ctx, "--- /dev/null");
> patch_id_addf(&ctx, "+++ b/%.*s", len2, p->two->path);
>
> Or I may be going overboard by bringing "addf" into the mix X-<.
I think there are two things going on in your example.
One is that obviously patch_id_addf() removes the spaces from the
result. But we could do that now by keeping the big strbuf_addf(), and
then just walking the result and feeding non-spaces.
The second is that your addf means we are back to formatting everything
into a buffer again. And it has to be dynamic to handle the final line
there, because "len2" isn't bounded. At which point we may as well go
back to sticking it all in one big strbuf (your example also breaks it
down line by line, but we could do that with separte strbuf_addf calls,
too).
Or you have to reimplement the printf format-parsing yourself, and write
into the sha1 instead of into the buffers. But that's probably insane.
I think the "no extra buffer with whitespace" combo is more like:
void patch_id_add_buf(git_SHA1_CTX *ctx, const char *buf, size_t len)
{
for (; len > 0; buf++, len--) {
if (!isspace(*buf))
git_SHA1_Update(ctx, buf, 1);
}
}
void patch_id_add_str(git_SHA1_CTX *ctx, const char *str)
{
patch_id_add_buf(ctx, strlen(str));
}
void patch_id_add_mode(git_SHA1_CTX *ctx, unsigned mode)
{
char buf[16]; /* big enough... */
int len = xsnprintf(buf, "%06o", mode);
patch_id_add_buf(ctx, buf, len);
}
patch_id_add_str(&ctx, "new file mode");
patch_id_add_mode(&ctx, p->two->mode);
patch_id_add_str(&ctx, "--- /dev/null");
patch_id_add_str(&ctx, "+++ b/");
patch_id_add_buf(&ctx, p->two->path, len2);
I dunno. I wondered if feeding single bytes to the sha1 update might
actually be noticeably slower, because I would assume that internally it
generally copies data in larger chunks. I didn't measure it, though.
-Peff
next prev parent reply other threads:[~2017-03-29 3:41 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-28 19:42 [PATCH 0/18] snprintf cleanups Jeff King
2017-03-28 19:45 ` [PATCH 01/18] do not check odb_mkstemp return value for errors Jeff King
2017-03-28 19:45 ` [PATCH 02/18] odb_mkstemp: write filename into strbuf Jeff King
2017-03-28 19:45 ` [PATCH 03/18] odb_mkstemp: use git_path_buf Jeff King
2017-03-28 19:46 ` [PATCH 04/18] diff: avoid fixed-size buffer for patch-ids Jeff King
2017-03-28 19:50 ` Jeff King
2017-03-28 19:46 ` [PATCH 05/18] tag: use strbuf to format tag header Jeff King
2017-03-28 19:46 ` [PATCH 06/18] fetch: use heap buffer to format reflog Jeff King
2017-03-28 19:46 ` [PATCH 07/18] avoid using fixed PATH_MAX buffers for refs Jeff King
2017-04-17 6:00 ` Junio C Hamano
2017-04-18 3:18 ` Jeff King
2017-04-18 4:55 ` Junio C Hamano
2017-03-28 19:46 ` [PATCH 08/18] avoid using mksnpath " Jeff King
2017-03-28 19:46 ` [PATCH 09/18] create_branch: move msg setup closer to point of use Jeff King
2017-03-28 19:46 ` [PATCH 10/18] create_branch: use xstrfmt for reflog message Jeff King
2017-03-28 19:46 ` [PATCH 11/18] name-rev: replace static buffer with strbuf Jeff King
2017-03-28 19:46 ` [PATCH 12/18] receive-pack: print --pack-header directly into argv array Jeff King
2017-03-28 19:46 ` [PATCH 13/18] replace unchecked snprintf calls with heap buffers Jeff King
2017-03-28 19:46 ` [PATCH 14/18] combine-diff: replace malloc/snprintf with xstrfmt Jeff King
2017-03-28 19:46 ` [PATCH 15/18] convert unchecked snprintf into xsnprintf Jeff King
2017-03-28 19:47 ` [PATCH 16/18] transport-helper: replace checked snprintf with xsnprintf Jeff King
2017-03-28 19:47 ` [PATCH 17/18] gc: replace local buffer with git_path Jeff King
2017-03-28 19:48 ` [PATCH 18/18] daemon: use an argv_array to exec children Jeff King
2017-03-28 22:33 ` [PATCH 0/18] snprintf cleanups Junio C Hamano
2017-03-29 3:41 ` Jeff King [this message]
2017-03-29 16:05 ` Junio C Hamano
2017-03-30 6:27 ` Jeff King
2017-03-30 17:24 ` Junio C Hamano
2017-03-30 18:26 ` Jeff King
2017-03-29 7:10 ` [PATCH] Makefile: detect errors in running spatch 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=20170329034105.bfgh4tutgrmjp2lc@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).