Re: [PATCH v4 6/8] dir: fix checks on common prefix directory

From: Elijah Newren <newren@gmail.com>
Date: Dec 20, 2019, 17:00 UTC
Message-ID: <CABPp-BEe7=LfR5KJriu1Lq-v5SVET-zm3GK3ZPjOYuLHrxqimg@mail.gmail.com>
In-Reply-To: <20191219222403.GA705525@coredump.intra.peff.net>

Hi Peff,

On Thu, Dec 19, 2019 at 2:24 PM Jeff King <peff@peff.net> wrote:

Show 15 quoted lines

>
> On Thu, Dec 19, 2019 at 12:23:29PM -0800, Elijah Newren wrote:
>
> > > >       while (len && path[len - 1] == '/')
> > > >               len--;
> > > >       if (!len)
> > > >               return 1;
> > > > +
> > > > +     de = xcalloc(1, sizeof(struct dirent)+len+1);
> > >
> > > That "+len+1" may deserve a comment?
> >
> > Good point, I'll add one and send a re-roll.
>
> Please use st_add3() while you are at it.

I would, but Junio already took the patches and applied them to next already. (I am curious, though, why we're worried about overflow in a context like this?)

> I'd also usually suggest FLEX_ALLOC_MEM() for even more simplicity, but
> it looks like filling the string is handled separately (and done many
> times).

Yes, the string is handled separately; I don't manufacture a dirent per leading directory component of the common prefix, but just allocate one and re-use it.

Show 6 quoted lines

> I have to wonder, though, if it wouldn't be simpler to move away from
> "struct dirent" here (and it looks like Junio suggested the same earlier
> in the thread). I don't know this code very well, but it looks
> like it could easily get by passing around a name pointer and a dtype
> through the cached_dir. The patch below seems like it's not too bad a
> cleanup, but possibly the names could be better.

This was mentioned twice upthread, first by me then by Junio (and I'll include my final response too):

Show 16 quoted lines

>>> I need to manufacture a dirent myself; short of that, the most
>>> likely alternative is to drop patches 2 & 5-8 of this series and
>>> throw my hands in the air and give up.
>>> ...
>>> It'd be an awful lot of work to rip [dirent] out...unless someone
>>> else has some bright ideas about something clever we can do, then I
>>> think this problem blows up in complexity to a level where I don't
>>> think it's worth addressing.
>>> ...
>>> Any bright ideas about what to do here?
>>
>> Restructuring the code so that we do not use "struct dirent" in the
>> first place, even in the original code that used only those obtained
>> from readdir(), perhaps?
>
> Okay, I'll submit a new series dropping most the patches.

It's possible I vastly overestimated how much work ripping out the dirent would be; I mean I've mis-estimated absolutely everything in dir.c and assumed each "little" thing would all be a small amount of work, so maybe I'm just swinging the pendulum too far the other way. But, although I think this alternative would be the cleanest, I saw a couple things that looked like this was going to turn into a huge can of worms when I started to peek at what it all touched. I'd be happy for someone to take this route, but it won't be me (see also https://lore.kernel.org/git/CABPp-BEkX9cH1=r3dJ4WLzcJKVcF-KpGUkshL34MMp3Xhhhpuw@mail.gmail.com/).

Elijah