From: ZheNing Hu <adlternative@gmail.com>
To: Christian Couder <christian.couder@gmail.com>
Cc: ZheNing Hu via GitGitGadget <gitgitgadget@gmail.com>,
git <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>,
Jeff King <peff@peff.net>,
Christian Couder <chriscool@tuxfamily.org>,
Hariom Verma <hariom18599@gmail.com>
Subject: Re: [PATCH 2/2] [GSOC][RFC] ref-filter: introduce enum atom_type
Date: Sun, 9 May 2021 21:40:37 +0800 [thread overview]
Message-ID: <CAOLTT8TGa2U=O6jAOcmqVwiKv6RiSt5j7FuA_XTO=JVi73ts2w@mail.gmail.com> (raw)
In-Reply-To: <CAP8UFD0mOmqWUS49wywDVoWOyAkCRSUY5+i7Gqq-ZZSNCr-jvg@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> 于2021年5月9日周日 下午2:21写道：
>
> > At the same time, The value of an atom_type is the coordinate
> > of its corresponding valid_atom entry, we can quickly index
> > to the corresponding valid_atom entry by the atom_type value.
>
> I am not sure it's worth having an atom_type field for each valid_atom
> element if the value of that field is already the index of the
> element, because then one would always be able to replace
> `valid_atom[i].atom_type` with just `i`. Or is it for some kind of
> type safety issue?
>
Well, I think the security issue here is just to allow used_atom and valid_atom
to be correctly mapped through atom_type. We don’t want the coder to forget to
update "enum atom_type" when adding new atoms to valid_atom in the future.
So maybe Junio's suggestion is reasonable, we delete the member atom_type in
valid_atom, but maintain the connection between atom_type and valid_atom items
by specifying atom_type as array coordinates.
> I wonder if the enum should be instead defined like this:
>
> enum atom_type {
> ATOM_UNKNOWN = 0,
> ATOM_REFNAME,
> ...
> ATOM_ELSE,
> ATOM_INVALID, /* should be last */
> };
>
> As a struct containing an atom_type would typically be initialized
> with 0 after being allocated, `ATOM_UNKNOWN = 0` could ensure that we
> can easily distinguish such a struct where the atom_type is known from
> such a struct where it is unknown yet.
>
> Having ATOM_INVALID as always the last enum value (even if some new
> ones are added later) could help us iterate over the valid atoms using
> something like:
>
> for (i = ATOM_UNKNOWN + 1; i < ATOM_INVALID; i++)
> /* do something with valid_atom[i] */;
>
Thanks, this suggestion is good!
> > +
> > /*
> > * An atom is a valid field atom listed below, possibly prefixed with
> > * a "*" to denote deref_tag().
> > @@ -122,6 +166,7 @@ static struct used_atom {
> > const char *name;
> > cmp_type type;
> > info_source source;
> > + enum atom_type atom_type;
> > union {
> > char color[COLOR_MAXLEN];
> > struct align align;
> > @@ -500,53 +545,54 @@ static int head_atom_parser(const struct ref_format *format, struct used_atom *a
> > }
> >
> > static struct {
> > + enum atom_type atom_type;
> > const char *name;
> > info_source source;
> > cmp_type cmp_type;
>
> I can see that the fields are already not in the same order as in
> struct used_atom, but my opinion is that it would be better if they
> would we as much as possible in the same order. Maybe one day we could
> even unify these structs in some way.
>
Yes, atom_value, valid_atom, used_atom, It may be difficult to read for the
first time. Maybe unifying them is a good direction for the future.
> Also as discussed above we might not even need to add an atom_type to
> valid_atom[].
>
OK.
> > int (*parser)(const struct ref_format *format, struct used_atom *atom,
> > const char *arg, struct strbuf *err);
> > } valid_atom[] = {
>
> > @@ -628,6 +674,7 @@ static int parse_ref_filter_atom(const struct ref_format *format,
> > at = used_atom_cnt;
> > used_atom_cnt++;
> > REALLOC_ARRAY(used_atom, used_atom_cnt);
> > + used_atom[at].atom_type = valid_atom[i].atom_type;
>
> As discussed above, if the value of an atom_type is the coordinate of
> its corresponding valid_atom entry, then here the following would be
> simpler:
>
> used_atom[at].atom_type = i;
>
I agree.
> > used_atom[at].name = xmemdupz(atom, ep - atom);
> > used_atom[at].type = valid_atom[i].cmp_type;
> > used_atom[at].source = valid_atom[i].source;
> > @@ -652,7 +699,7 @@ static int parse_ref_filter_atom(const struct ref_format *format,
> > return -1;
> > if (*atom == '*')
> > need_tagged = 1;
> > - if (!strcmp(valid_atom[i].name, "symref"))
> > + if (valid_atom[i].atom_type == ATOM_SYMREF)
>
> In the same way as above, the above line might be replaced with the simpler:
>
> if (i == ATOM_SYMREF)
>
> > need_symref = 1;
> > return at;
> > }
Thanks!
--
ZheNing Hu
next prev parent reply other threads:[~2021-05-09 13:40 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-08 15:22 [PATCH 0/2] [GSOC][RFC] ref-filter: introduce enum atom_type ZheNing Hu via GitGitGadget
2021-05-08 15:22 ` [PATCH 1/2] [GSOC] ref-filter: add objectsize to used_atom ZheNing Hu via GitGitGadget
2021-05-08 15:22 ` [PATCH 2/2] [GSOC][RFC] ref-filter: introduce enum atom_type ZheNing Hu via GitGitGadget
2021-05-09 6:21 ` Christian Couder
2021-05-09 8:26 ` Junio C Hamano
2021-05-09 13:44 ` ZheNing Hu
2021-05-09 13:40 ` ZheNing Hu [this message]
2021-05-10 15:03 ` [PATCH v2 0/2] " ZheNing Hu via GitGitGadget
2021-05-10 15:03 ` [PATCH v2 1/2] [GSOC] ref-filter: add objectsize to used_atom ZheNing Hu via GitGitGadget
2021-05-10 15:03 ` [PATCH v2 2/2] [GSOC] ref-filter: introduce enum atom_type ZheNing Hu via GitGitGadget
2021-05-11 2:14 ` Junio C Hamano
2021-05-11 5:51 ` Christian Couder
2021-05-11 6:12 ` Junio C Hamano
2021-05-11 12:53 ` ZheNing Hu
2021-05-11 12:37 ` ZheNing Hu
2021-05-11 13:05 ` Junio C Hamano
2021-05-11 12:18 ` ZheNing Hu
2021-05-12 12:11 ` [PATCH v3 0/2] [GSOC][RFC] " ZheNing Hu via GitGitGadget
2021-05-12 12:11 ` [PATCH v3 1/2] [GSOC] ref-filter: add objectsize to used_atom ZheNing Hu via GitGitGadget
2021-05-12 23:11 ` Junio C Hamano
2021-05-13 9:04 ` ZheNing Hu
2021-05-12 12:11 ` [PATCH v3 2/2] [GSOC] ref-filter: introduce enum atom_type ZheNing Hu via GitGitGadget
2021-05-12 23:21 ` Junio C Hamano
2021-05-13 9:25 ` ZheNing Hu
2021-05-13 15:15 ` [PATCH v4 0/2] [GSOC][RFC] " ZheNing Hu via GitGitGadget
2021-05-13 15:15 ` [PATCH v4 1/2] [GSOC] ref-filter: add objectsize to used_atom ZheNing Hu via GitGitGadget
2021-05-13 15:15 ` [PATCH v4 2/2] [GSOC] ref-filter: introduce enum atom_type ZheNing Hu via GitGitGadget
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='CAOLTT8TGa2U=O6jAOcmqVwiKv6RiSt5j7FuA_XTO=JVi73ts2w@mail.gmail.com' \
--to=adlternative@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=hariom18599@gmail.com \
--cc=peff@peff.net \
/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.