On Fri, Jan 28, 2022 at 10:15 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> > knowledge there shouldn't be any more issues my series. The only
> > question that remains open is Han-Wen's [2], but as I replied I'm not
> > sure we actually need to adjust documentation of the flags given that we
> > already do explicitly say how we pass through flags in all cases.
>
> I'll let Han-Wen answer this first.
I've recently been working on ref iteration, and it's a pretty
confusing area, because the iterator has flags (should it skip broken
refs, etc.) , and the refs themselves have flags (is the ref broken),
and some code must manipulate both in the same function: the ref
iterator structure has a member `flags`, but it's not the flags passed
to ref_iterator_begin(). In code, this all looks like `flags`, the
compiler does no type checking, and it is often hard to see which bit
field goes where. Here we have another thing called `flags` added in a
context where the meaning of the flags can be ambiguous.
If you want to add another instance, that in itself seems fine,
because there is plenty of precedent across the code for this.
My questions:
* am I the only one who struggles with the different flavor of `flags` ?
* if no, what should be done about this? Maybe
typedef unsigned int ref_flags;
#define REF_IS_SYMREF 0x1
char *refs_resolve_ref_unsafe(const char *refname, ref_flags *flags, ... );
or
typedef enum ref_flags {
REF_IS_SYMREF = 0x1,
};
char *refs_resolve_ref_unsafe(const char *refname, enum ref_flags
*flags, ... );
A somewhat related gripe is that some code uses `int flags` and other
code uses `unsigned flags`. It would be great to standardize this.
--
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--
Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
