Re: [PATCH 2/2] [GSOC][RFC] ref-filter: introduce enum atom_type
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 9, 2021, 08:26 UTC
- Message-ID
- <xmqqh7jctiru.fsf@gitster.g>
- In-Reply-To
- <CAP8UFD0mOmqWUS49wywDVoWOyAkCRSUY5+i7Gqq-ZZSNCr-jvg@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
Show 5 quoted lines
> 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?
Show 21 quoted lines
> 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] */;OK.
As to "safety", I think it still makes sense to declare "enum", but I agree that we do not necessarily have to have it in the valid_atom[] struct. We could do something like this instead:
static struct {
const char *name;
info_source source;
cmp_type cmp_type;
int (*parser)(const struct ref_format *format, struct used_atom *atom,
const char *arg, struct strbuf *err);
} valid_atom[] = {
[ATOM_REFNAME] = { "refname", SOURCE_NONE, FIELD_STR, refname_atom_parser },
[ATOM_OBJECTTYPE] = { "objecttype", SOURCE_OTHER, FIELD_STR, objecttype...
[ATOM_OBJECTSIZE] = { "objectsize", SOURCE_OTHER, FIELD_ULONG, objectsi...
...