From: Junio C Hamano <gitster@pobox•com>
To: Karthik Nayak <karthik.188@gmail•com>
Cc: Git <git@vger•kernel.org>, Eric Sunshine <sunshine@sunshineco•com>
Subject: Re: [PATCH v3 14/15] ref-filter: introduce contents_atom_parser()
Date: Thu, 07 Jan 2016 10:04:46 -0800 [thread overview]
Message-ID: <xmqqziwh4669.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAOLa=ZQY09yqDVELb9ObTnWfU-9nRyxJiV=_2tHbZPk_oe8sGQ@mail.gmail.com> (Karthik Nayak's message of "Wed, 6 Jan 2016 23:52:03 +0530")
Karthik Nayak <karthik.188@gmail•com> writes:
>>> +static void contents_atom_parser(struct used_atom *atom)
>>> +{
>>> + const char * buf;
const char *buf;
>>> +
>>> + if (match_atom_name(atom->name, "subject", &buf) && !buf) {
>>> + atom->u.contents.option = C_SUB;
>>> + return;
>>> + } else if (match_atom_name(atom->name, "body", &buf) && !buf) {
>>> + atom->u.contents.option = C_BODY_DEP;
>>> + return;
>>> + } if (!match_atom_name(atom->name, "contents", &buf))
>>> + die("BUG: parsing non-'contents'");
>>
>> Did you really intend to say "if" here, not "else if"?
>
> Not that it makes a difference here since both the previous
> condition return. I think "else if" would be better.
I am not sure if it is "Y would be better even though X and Y both
would work". It looks to me "X and Y behave differently, X is a bug
and Y is correct".
The above would behave differently between "if" and "else if" (and
by the way, the code layout suggests it is "else if"; otherwise you
would be starting "if" on its own line) when you feed "subject:foo",
no?
next prev parent reply other threads:[~2016-01-07 18:04 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-05 8:02 [PATCH v3 00/15] ref-filter: use parsing functions Karthik Nayak
2016-01-05 8:03 ` [PATCH v3 01/15] strbuf: introduce strbuf_split_str_omit_term() Karthik Nayak
2016-01-05 19:24 ` Junio C Hamano
2016-01-06 7:27 ` Karthik Nayak
2016-01-21 19:47 ` Eric Sunshine
2016-01-25 6:12 ` Karthik Nayak
2016-01-05 8:03 ` [PATCH v3 02/15] ref-filter: use strbuf_split_str_omit_term() Karthik Nayak
2016-01-05 8:03 ` [PATCH v3 03/15] ref-filter: bump 'used_atom' and related code to the top Karthik Nayak
2016-01-05 8:03 ` [PATCH v3 04/15] ref-filter: introduce struct used_atom Karthik Nayak
2016-01-21 19:04 ` Eric Sunshine
2016-01-25 6:13 ` Karthik Nayak
2016-01-05 8:03 ` [PATCH v3 05/15] ref-filter: introduce parsing functions for each valid atom Karthik Nayak
2016-01-05 8:03 ` [PATCH v3 06/15] ref-fitler: bump match_atom() name to the top Karthik Nayak
2016-01-05 8:03 ` [PATCH v3 07/15] ref-filter: skip deref specifier in match_atom_name() Karthik Nayak
2016-01-05 8:03 ` [PATCH v3 08/15] ref-filter: introduce color_atom_parser() Karthik Nayak
2016-01-05 20:49 ` Junio C Hamano
2016-01-06 7:52 ` Karthik Nayak
2016-01-05 21:06 ` Junio C Hamano
2016-01-06 10:16 ` Karthik Nayak
2016-01-05 8:03 ` [PATCH v3 09/15] ref-filter: introduce align_atom_parser() Karthik Nayak
2016-01-05 8:03 ` [PATCH v3 10/15] ref-filter: introduce parse_align_position() Karthik Nayak
2016-01-25 21:49 ` Eric Sunshine
2016-01-26 11:34 ` Karthik Nayak
2016-01-05 8:03 ` [PATCH v3 11/15] ref-filter: convert variable 'width' to an unsigned int Karthik Nayak
2016-01-05 21:12 ` Junio C Hamano
2016-01-06 10:17 ` Karthik Nayak
2016-01-05 8:03 ` [PATCH v3 12/15] ref-filter: align: introduce long-form syntax Karthik Nayak
2016-01-25 22:58 ` Eric Sunshine
2016-01-25 23:45 ` Junio C Hamano
2016-01-26 9:40 ` Karthik Nayak
2016-01-26 9:30 ` Karthik Nayak
2016-01-26 5:16 ` Christian Couder
2016-01-26 9:39 ` Karthik Nayak
2016-01-05 8:03 ` [PATCH v3 13/15] ref-filter: introduce remote_ref_atom_parser() Karthik Nayak
2016-01-26 0:28 ` Eric Sunshine
2016-01-26 10:02 ` Karthik Nayak
2016-01-05 8:03 ` [PATCH v3 14/15] ref-filter: introduce contents_atom_parser() Karthik Nayak
2016-01-05 21:22 ` Junio C Hamano
2016-01-06 18:22 ` Karthik Nayak
2016-01-07 18:04 ` Junio C Hamano [this message]
2016-01-07 20:03 ` Karthik Nayak
2016-01-05 8:03 ` [PATCH v3 15/15] ref-filter: introduce objectname_atom_parser() Karthik Nayak
2016-01-05 21:31 ` Junio C Hamano
2016-01-06 18:27 ` Karthik Nayak
2016-01-06 21:14 ` [PATCH v3 00/15] ref-filter: use parsing functions Eric Sunshine
2016-01-07 14:25 ` Karthik Nayak
2016-01-07 18:43 ` Junio C Hamano
2016-01-07 20:20 ` Karthik Nayak
2016-01-07 20:36 ` Eric Sunshine
2016-01-07 20:44 ` Karthik Nayak
2016-01-07 21:28 ` Junio C Hamano
2016-01-09 9:00 ` Karthik Nayak
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=xmqqziwh4669.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=karthik.188@gmail$(echo .)com \
--cc=sunshine@sunshineco$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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