From: "Lukas Sandström" <lukass@etek.chalmers.se>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: ! [PATCH/RFC] git-mailinfo: use strbuf's instead of fixed buffers
Date: Sun, 13 Jul 2008 20:17:41 +0200 [thread overview]
Message-ID: <487A46C5.6000503@etek.chalmers.se> (raw)
In-Reply-To: <7vy747fx9x.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Lukas Sandström <lukass@etek.chalmers.se> writes:
>
>> -static char *sanity_check(char *name, char *email)
>> +static void sanity_check(struct strbuf *out, struct strbuf *name, struct strbuf *email)
>> {
>> - int len = strlen(name);
>> - if (len < 3 || len > 60)
>> - return email;
>> - if (strchr(name, '@') || strchr(name, '<') || strchr(name, '>'))
>> - return email;
>> - return name;
>> + struct strbuf o = STRBUF_INIT;
>> + if (name->len < 3 || name->len > 60)
>> + strbuf_addbuf(&o, email);
>> + if (strchr(name->buf, '@') || strchr(name->buf, '<') ||
>> + strchr(name->buf, '>'))
>> + strbuf_addbuf(&o, email);
>> + strbuf_addbuf(&o, name);
>> + strbuf_reset(out);
>> + strbuf_addbuf(out, &o);
>> + strbuf_release(&o);
>
> This does not look like a correct conversion. When name is too short or
> too long, we do not even look at name and return email straight. Perhaps
> this would be more faithful conversion:
>
> struct strbuf *src = name;
> if (name->len < 3 ||
> 60 < name->len ||
> strchr(name->buf, '@') ||
> strchr(name->buf, '<') ||
> strchr(name->buf, '>'))
> src = email;
> else if (name == out)
> return;
> strbuf_reset(out);
> strbuf_addbuf(out, src);
>
> It is not your fault, but sanity_check() is a grave misnomer for this
> function. This does "get_sane_name" (i.e. we have name and email but if
> name does not look right, use email instead).
Right. I changed the name and used your implementation.
>> -static int bogus_from(char *line)
>> +static int bogus_from(const struct strbuf *line)
>> {
[ ... ]
>> return 1;
>> }
>
> Conversion looks correct but its return value does not make much sense
> (again, not your fault). bogus_from() is given a bogus looking from line
> (it is not about checking if it is bogus), and returns 0 if we already
> have e-mail address, if the from line does not have bra-ket for grabbing
> e-mail address for, but returns 1 if we managed to get name and email
> pairs. The inconsistency does not matter only because its sole caller
> handle_from() returns its return value, and its caller discards it. We
> may be better off declaring this function and handle_from() as void.
>
Done.
>> /* The remainder is name. It could be "John Doe <john.doe@xz>"
>> * or "john.doe@xz (John Doe)", but we have whited out the
>> * email part, so trim from both ends, possibly removing
>> * the () pair at the end.
>> */
>
> Now, it should read "but we have removed the email part", I think.
Done.
>> + strbuf_trim(from);
>> + if (*from->buf == '(')
>> + strbuf_remove(&name, 0, 1);
>> + if (*(from->buf + from->len - 1) == ')')
>
> Can from be empty at this point before this check?
>
Yes. Added a test for that.
>> + strbuf_setlen(from, from->len - 1);
>> +
>> + sanity_check(&name, from, &email);
>> return 1;
>> }
>
> We used to copy the data from the argument (in_line) before munging it in
> this function, but now we are modifying it in place (from). Does this
> upset our caller, or the original code was just doing an extra unnecessary
> copy?
No, it's ok with the current code, since when handle_from() is called, it's
the last time we look at the header[i] field. I changed it to copy its argument
anyway, for future-proofing.
>
>> -static int handle_header(char *line, char *data, int ofs)
>> +static void handle_header(struct strbuf **out, const struct strbuf *line)
>> {
>> - if (!line || !data)
>> - return 1;
>> -
>> - strcpy(data, line+ofs);
>> + if (!*out) {
>> + *out = xmalloc(sizeof(struct strbuf));
>> + strbuf_init(*out, line->len);
>> + } else
>> + strbuf_reset(*out);
>>
>> - return 0;
>> + strbuf_addbuf(*out, (struct strbuf *)line); /* const warning */
>> }
>
> I think its second parameter can safely become "const struct strbuf *";
> perhaps we should fix the definition of strbuf_addbuf() in your first
> patch?
>
Done.
>> @@ -173,180 +153,176 @@ static int slurp_attr(const char *line, const char *name, char *attr)
>> else
>> ends = "; \t";
>> sz = strcspn(ap, ends);
>> - memcpy(attr, ap, sz);
>> - attr[sz] = 0;
>> + strbuf_add(attr, ap, sz);
>> return 1;
>> }
>>
>> struct content_type {
>> - char *boundary;
>> - int boundary_len;
>> + struct strbuf *boundary;
>> };
>>
>> static struct content_type content[MAX_BOUNDARIES];
>
> Wouldn't it make more sense to get rid of "struct content_type" altogether
> and use "struct strbuf *content[MAX_BOUNDARIES]" directly?
Sure.
I'll send a patch updated with your comments shortly.
/Lukas
next prev parent reply other threads:[~2008-07-13 18:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-10 21:41 [PATCH] git-mailinfo: Fix getting the subject from the body Lukas Sandström
[not found] ` <7vod55o0tx.fsf@gitster.siamese.dyndns.org>
2008-07-10 22:37 ` Lukas Sandström
2008-07-10 23:25 ` Junio C Hamano
2008-07-10 23:41 ` [PATCH] Add some useful functions for strbuf manipulation Lukas Sandström
2008-07-10 23:43 ` [PATCH/RFC] git-mailinfo: use strbuf's instead of fixed buffers Lukas Sandström
2008-07-12 6:10 ` Junio C Hamano
2008-07-13 18:17 ` Lukas Sandström [this message]
2008-07-13 18:28 ` [PATCH] Make some strbuf_*() struct strbuf arguments const Lukas Sandström
2008-07-13 18:29 ` [PATCH] Add some useful functions for strbuf manipulation Lukas Sandström
2008-07-13 18:30 ` [PATCH] git-mailinfo: use strbuf's instead of fixed buffers Lukas Sandström
2008-07-13 21:37 ` Junio C Hamano
2008-07-12 9:36 ` [PATCH] git-mailinfo: Fix getting the subject from the body Junio C Hamano
2008-07-12 21:45 ` Lukas Sandström
2008-07-15 3:13 ` Don Zickus
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=487A46C5.6000503@etek.chalmers.se \
--to=lukass@etek.chalmers.se \
--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 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.