Re: [PATCH v2 8/8] refs: explicitly propagate errno from refs_read_raw_ref
- From
Han-Wen Nienhuys <hanwen@google.com>
- Date
- Jul 5, 2021, 19:39 UTC
- Message-ID
- <CAFQ2z_MuZJ7FmaZ8pjb51dhSHuHYipesHn8hum3Af49qwiZL6Q@mail.gmail.com>
- In-Reply-To
- <877di47e2j.fsf@evledraar.gmail.com>
On Mon, Jul 5, 2021 at 9:31 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
Show 6 quoted lines
> > and the case you pointed out is the only one which inspects errno > > after calling resolve_ref_unsafe (transitively through the grepped > > functions.) > > Isn't the `errno == EISDIR` in files_copy_or_rename_ref() another one? > It's just after calling refs_read_ref_full().
no. It's handling the EISDIR for refs_delete_ref.
Show 12 quoted lines
> > I'll take from this review that I should elide the part where errno is > > cleared, and leave it to someone else to figure out a more holistic > > strategy to error reporting. > > ...or if we don't clear errno introducing those sorts of subtle bugs > when we use reftable instead of the files backend. I.e. no, we really > should be clearing errno, if not in this series then in some other > pre-reftable series. > > To not do so would be kicking this particular can down the road, and > leaving those bugs for reftable users to find. Which given that I've > found a few cases with no test coverage...
too late :-)
I've already kicked the can down the road by not clearing errno in the current version of the series.
-- 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