Re: [PATCH v2 1/6] commit: provide a function to find a header in a buffer

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 27, 2014, 19:05 UTC
Message-ID: <xmqqwq9tda8t.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20140827180016.GA6269@peff.net>

Jeff King <peff@peff.net> writes:

Show 20 quoted lines

> On Wed, Aug 27, 2014 at 10:30:22AM -0700, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> 
>> > +const char *find_commit_header(const char *msg, const char *key, size_t *out_len)
>> [...]
>> 
>> Hmph.  Does this have to worry about continuation lines in the
>> header part e.g. mergetag?  If the original in pretty.c was only
>> about the encoding, it may not have mattered, but now because it is
>> made public, it may matter more.
>
> If you mean parsing past continuation lines, then no, we do not need to
> worry. We go line by line and look for the key at the beginning of a
> line, so we would skip past any continuation lines.
>
> If you mean including continuation lines in the output, I don't think
> that's a good idea here. It would mean the function would have to copy
> the value out (to get rid of the continuation whitespace) rather than
> point directly into the msg buffer.

I meant the counting of out_len. You do not copy the contents for the caller for a single line case either, so I wouldn't expect it.

You locate where the stuff begins to make it easier for the caller to read or copy, and the caller may choose to stop reading from the location up to out_len bytes, or it may choose to ignore out_len and stop at the first newline. For the latter kind of caller, it does not matter if out_len does not point at the end of the "field" (i.e. for a continued-line case), but for the former, wouldn't it be more useful if out_len told where the end of the "field" is?