git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Brandon Casey <bcasey@nvidia.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Brandon Casey <drafnel@gmail.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>,
	"pclouds@gmail.com" <pclouds@gmail.com>,
	"jrnieder@gmail.com" <jrnieder@gmail.com>
Subject: Re: [PATCH v4 05/12] sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
Date: Tue, 12 Feb 2013 11:49:47 -0800	[thread overview]
Message-ID: <511A9CDB.9060008@nvidia.com> (raw)
In-Reply-To: <7vtxphfhoq.fsf@alter.siamese.dyndns.org>

On 2/12/2013 11:36 AM, Junio C Hamano wrote:
> Brandon Casey <bcasey@nvidia.com> writes:
> 
>>>> +	return len > strlen(cherry_picked_prefix) + 1 &&
>>>> +		!prefixcmp(buf, cherry_picked_prefix) && buf[len - 1] == ')';
>>>> +}
>>>
>>> Does the first "is it longer than the prefix?" check matter?  If it
>>> is not, prefixcmp() would not match anyway, no?
>>
>> Probably not in practice, but technically we should only be accessing
>> len characters in buf even though buf may be longer than len.  So the
>> check is just making sure the function doesn't access chars it's not
>> supposed to.
> 
> Sorry, I do not follow.  Isn't caller's buf terminated with LF at buf[len],
> which would never match cherry_picked_prefix even if len is shorter
> than the prefix?

Heh, I almost pointed that out in my reply.  Yes, buf will be terminated
with LF at buf[len].  And yes, that means that we will never get a false
positive from prefixcmp even if the comparison overruns buf+len while
doing its comparison.  That's why the check doesn't matter in practice,
i.e. based on the way that is_cherry_picked_from_line is being called
right now and the content of cherry_picked_prefix.

But, hasn't is_cherry_picked_from_line entered into a contract with the
caller and said "I will not access more than len characters"?

It's ok with me if you think it reads better without the check.

-Brandon


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

  reply	other threads:[~2013-02-12 19:50 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-12 10:17 [PATCH v4 00/12] unify appending of sob Brandon Casey
2013-02-12 10:17 ` [PATCH v4 01/12] sequencer.c: rework search for start of footer to improve clarity Brandon Casey
2013-02-12 10:17 ` [PATCH v4 02/12] commit, cherry-pick -s: remove broken support for multiline rfc2822 fields Brandon Casey
2013-02-12 10:17 ` [PATCH v4 03/12] t/test-lib-functions.sh: allow to specify the tag name to test_commit Brandon Casey
2017-05-13 17:41   ` Ævar Arnfjörð Bjarmason
2013-02-12 10:17 ` [PATCH v4 04/12] t/t3511: add some tests of 'cherry-pick -s' functionality Brandon Casey
2013-02-12 10:17 ` [PATCH v4 05/12] sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer Brandon Casey
2013-02-12 19:13   ` Junio C Hamano
2013-02-12 19:32     ` Brandon Casey
2013-02-12 19:36       ` Junio C Hamano
2013-02-12 19:49         ` Brandon Casey [this message]
2013-02-12 19:58           ` Junio C Hamano
2013-02-12 19:45       ` Jonathan Nieder
2013-02-12 10:17 ` [PATCH v4 06/12] sequencer.c: require a conforming footer to be preceded by a blank line Brandon Casey
2013-02-12 10:17 ` [PATCH v4 07/12] sequencer.c: always separate "(cherry picked from" from commit body Brandon Casey
2013-02-12 10:17 ` [PATCH v4 08/12] sequencer.c: teach append_signoff how to detect duplicate s-o-b Brandon Casey
2013-02-12 10:17 ` [PATCH v4 09/12] sequencer.c: teach append_signoff to avoid adding a duplicate newline Brandon Casey
2013-02-12 10:33   ` [PATCH v4.1 " Brandon Casey
2013-02-14 17:58     ` John Keeping
2013-02-15 18:58       ` Brandon Casey
2013-02-17 22:49         ` John Keeping
2013-02-21 18:51     ` Junio C Hamano
2013-02-21 20:26       ` Brandon Casey
2013-02-21 20:29         ` Brandon Casey
2013-02-21 21:27         ` Junio C Hamano
2013-02-22  9:25           ` [PATCH] git-commit: populate the edit buffer with 2 blank lines before s-o-b Brandon Casey
2013-02-22 18:35             ` Junio C Hamano
2013-02-22 22:03               ` Brandon Casey
2013-02-22 22:05                 ` [PATCH v2] " Brandon Casey
2013-02-22 22:35                   ` Jeff King
2013-02-22 22:38                     ` Junio C Hamano
2013-02-12 10:17 ` [PATCH v4 10/12] t4014: more tests about appending s-o-b lines Brandon Casey
2013-02-12 10:17 ` [PATCH v4 11/12] format-patch: update append_signoff prototype Brandon Casey
2013-02-12 19:29   ` Junio C Hamano
2013-02-12 22:51     ` Brandon Casey
2013-02-12 10:17 ` [PATCH v4 12/12] Unify appending signoff in format-patch, commit and sequencer Brandon Casey
2013-02-12 10:17 ` [PATCH/FYI v4 13/12] fixup! t/t3511: add some tests of 'cherry-pick -s' functionality Brandon Casey
2013-02-12 19:56   ` Jonathan Nieder
2013-02-12 20:20     ` Junio C Hamano
2013-02-12 20:16 ` [PATCH v4 00/12] unify appending of sob Jonathan Nieder
2013-02-12 20:45   ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=511A9CDB.9060008@nvidia.com \
    --to=bcasey@nvidia.com \
    --cc=drafnel@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=pclouds@gmail.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).