All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Christian Couder <chriscool@tuxfamily.org>,
	Jakub Narebski <jnareb@gmail.com>,
	Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH 12/15] use get_commit_buffer everywhere
Date: Tue, 10 Jun 2014 09:06:35 -0700	[thread overview]
Message-ID: <xmqqioo8agvo.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20140610000223.GA20644@sigill.intra.peff.net> (Jeff King's message of "Mon, 9 Jun 2014 20:02:24 -0400")

Jeff King <peff@peff.net> writes:

> I agree it's not right, though. I think the original is questionable,
> too. It takes a pointer into the middle of partial_commit->buffer and
> attaches it to a strbuf. That's wrong because:
>
>   1. It's pointing into the middle of an allocated buffer, not the
>      beginning.
>
>   2. We do not own partial_commit->buffer in the first place.
>
> So any call to strbuf_detach on the result would be disastrous.

You are right.  Where did this original crap come from X-<...

> ... and it
> doesn't cause a bug in practice because the only use of the strbuf is to
> pass it as a const to create_notes_commit.
>
> I feel like the most elegant solution is for create_notes_commit to take
> a buf/len pair rather than a strbuf, but it unfortunately is just
> feeding that to commit_tree. Adjusting that code path would affect quite
> a few other spots.
>
> The other obvious option is actually populating the strbuf, but it feels
> ugly to have to make a copy just to satisfy the function interface.
>
> Maybe a cast and a warning comment are the least evil thing, as below? I
> dunno, it feels pretty wrong.

Yeah, it does feel wrong wrong wrong.  Perhaps this big comment
would serve as a marker for a low-hanging fruit for somebody else to
fix it, e.g. by using strbuf-add to make a copy, which would be the
easiest and safest workaround?

> diff --git a/notes-merge.c b/notes-merge.c
> index 94a1a8a..1f3b309 100644
> --- a/notes-merge.c
> +++ b/notes-merge.c
> @@ -671,7 +671,7 @@ int notes_merge_commit(struct notes_merge_options *o,
>  	DIR *dir;
>  	struct dirent *e;
>  	struct strbuf path = STRBUF_INIT;
> -	char *msg = strstr(partial_commit->buffer, "\n\n");
> +	const char *msg = strstr(partial_commit->buffer, "\n\n");
>  	struct strbuf sb_msg = STRBUF_INIT;
>  	int baselen;
>  
> @@ -719,7 +719,15 @@ int notes_merge_commit(struct notes_merge_options *o,
>  		strbuf_setlen(&path, baselen);
>  	}
>  
> -	strbuf_attach(&sb_msg, msg, strlen(msg), strlen(msg) + 1);
> +	/*
> +	 * This is a bit tricky. We should not be attaching msg, which
> +	 * is not owned by us and is not even the start of a heap buffer, to a
> +	 * strbuf. But the create_notes_commit interface really wants
> +	 * a strbuf, even though it will only ever use it as a buf/len pair and
> +	 * never modify it. So this is tentatively safe as long as nobody ever
> +	 * modifies, detaches, or releases the strbuf.
> +	 */
> +	strbuf_attach(&sb_msg, (char *)msg, strlen(msg), strlen(msg) + 1);
>  	create_notes_commit(partial_tree, partial_commit->parents, &sb_msg,
>  			    result_sha1);
>  	if (o->verbosity >= 4)
>
> I'm still confused and disturbed that my gcc is not noticing this
> obvious const violation. Hmm, shutting off ccache seems to make it work.
> Doubly disturbing.
>
> -Peff

  parent reply	other threads:[~2014-06-10 16:06 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-09 18:02 [PATCH 0/15] store length of commit->buffer Jeff King
2014-06-09 18:09 ` [PATCH 01/15] alloc: include any-object allocations in alloc_report Jeff King
2014-06-09 18:09 ` [PATCH 02/15] commit: push commit_index update into alloc_commit_node Jeff King
2014-06-10 21:31   ` Junio C Hamano
2014-06-09 18:10 ` [PATCH 03/15] do not create "struct commit" with xcalloc Jeff King
2014-06-10 21:35   ` Junio C Hamano
2014-06-10 21:49     ` Jeff King
2014-06-09 18:10 ` [PATCH 04/15] logmsg_reencode: return const buffer Jeff King
2014-06-10  1:36   ` Eric Sunshine
2014-06-09 18:10 ` [PATCH 05/15] sequencer: use logmsg_reencode in get_message Jeff King
2014-06-10 21:40   ` Junio C Hamano
2014-06-10 21:50     ` Jeff King
2014-06-09 18:11 ` [PATCH 06/15] provide a helper to free commit buffer Jeff King
2014-06-09 18:11 ` [PATCH 07/15] provide a helper to set the " Jeff King
2014-06-09 18:11 ` [PATCH 08/15] provide helpers to access " Jeff King
2014-06-10  8:00   ` Eric Sunshine
2014-06-09 18:12 ` [PATCH 09/15] use get_cached_commit_buffer where appropriate Jeff King
2014-06-09 18:12 ` [PATCH 10/15] use get_commit_buffer to avoid duplicate code Jeff King
2014-06-10  8:01   ` Eric Sunshine
2014-06-10 20:34     ` Jeff King
2014-06-09 18:13 ` [PATCH 11/15] convert logmsg_reencode to get_commit_buffer Jeff King
2014-06-09 18:13 ` [PATCH 12/15] use get_commit_buffer everywhere Jeff King
2014-06-09 22:40   ` Junio C Hamano
2014-06-10  0:02     ` Jeff King
2014-06-10  0:22       ` Jeff King
2014-06-10 16:06       ` Junio C Hamano [this message]
2014-06-10 21:27         ` Jeff King
2014-06-09 18:15 ` [PATCH 13/15] commit-slab: provide a static initializer Jeff King
2014-06-09 18:15 ` [PATCH 14/15] commit: convert commit->buffer to a slab Jeff King
2014-06-09 18:15 ` [PATCH 15/15] commit: record buffer length in cache Jeff King
2014-06-10  5:12   ` Christian Couder
2014-06-10  5:27     ` Jeff King
2014-06-10 20:33       ` Jeff King
2014-06-10 21:30         ` Christian Couder
2014-06-10 21:35 ` [PATCH v2 0/17] store length of commit->buffer Jeff King
2014-06-10 21:36   ` [PATCH 01/17] commit_tree: take a pointer/len pair rather than a const strbuf Jeff King
2014-06-10 21:38   ` [PATCH 02/17] replace dangerous uses of strbuf_attach Jeff King
2014-06-10 21:38   ` [PATCH 03/17] alloc: include any-object allocations in alloc_report Jeff King
2014-06-10 21:39   ` [PATCH 04/17] commit: push commit_index update into alloc_commit_node Jeff King
2014-06-10 21:39   ` [PATCH 05/17] do not create "struct commit" with xcalloc Jeff King
2014-06-10 21:39   ` [PATCH 06/17] logmsg_reencode: return const buffer Jeff King
2014-06-10 21:39   ` [PATCH 07/17] sequencer: use logmsg_reencode in get_message Jeff King
2014-06-10 21:40   ` [PATCH 08/17] provide a helper to free commit buffer Jeff King
2014-06-12 18:22     ` Junio C Hamano
2014-06-12 20:08       ` Jeff King
2014-06-12 22:05         ` Jeff King
2014-06-10 21:40   ` [PATCH 09/17] provide a helper to set the " Jeff King
2014-06-10 21:40   ` [PATCH 10/17] provide helpers to access " Jeff King
2014-06-10 21:40   ` [PATCH 11/17] use get_cached_commit_buffer where appropriate Jeff King
2014-06-10 21:41   ` [PATCH 12/17] use get_commit_buffer to avoid duplicate code Jeff King
2014-06-10 21:41   ` [PATCH 13/17] convert logmsg_reencode to get_commit_buffer Jeff King
2014-06-10 21:41   ` [PATCH 14/17] use get_commit_buffer everywhere Jeff King
2014-06-10 21:42   ` [PATCH 15/17] commit-slab: provide a static initializer Jeff King
2014-06-12 18:15     ` Junio C Hamano
2014-06-12 19:51       ` Jeff King
2014-06-10 21:43   ` [PATCH 16/17] commit: convert commit->buffer to a slab Jeff King
2014-06-10 21:44   ` [PATCH 17/17] commit: record buffer length in cache Jeff King
2014-06-10 21:46   ` [PATCH v2 0/17] store length of commit->buffer Jeff King
2014-06-12 17:22     ` Junio C Hamano
2014-06-13  6:32   ` [PATCH v2] reuse cached commit buffer when parsing signatures 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=xmqqioo8agvo.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    --cc=peff@peff.net \
    --cc=sunshine@sunshineco.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.