Re: What's cooking in git.git (Dec 2019, #04; Tue, 17)

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 18, 2019, 18:01 UTC
Message-ID: <xmqqsglhecnb.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CABPp-BGRjewgHtFQ7F_isrqnC25EQyWoPbpdyVJeDzfVEysiCg@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 21 quoted lines

> On Tue, Dec 17, 2019 at 2:03 PM Junio C Hamano <gitster@pobox.com> wrote:
>
>> * en/fill-directory-fixes (2019-12-11) 8 commits
>>  - dir: consolidate similar code in treat_directory()
>>  - dir: synchronize treat_leading_path() and read_directory_recursive()
>>  - dir: fix checks on common prefix directory
>>  - dir: break part of read_directory_recursive() out for reuse
>>  - dir: exit before wildcard fall-through if there is no wildcard
>>  - dir: remove stray quote character in comment
>>  - Revert "dir.c: make 'git-status --ignored' work within leading directories"
>>  - t3011: demonstrate directory traversal failures
>>
>>  Assorted fixes to the directory traversal API.
>>
>>  Will merge to 'next'.
>
> Please hold; even if you are willing to accept a manufactured dirent,
> the discussion did highlight two bugs in this series:
>
> 1) I shouldn't assume dirent has a d_type member; my one access to it
> should be guarded with a !defined(NO_D_TYPE_IN_DIRENT).

Thanks, yes, that should be done.

Show 6 quoted lines

>
> 2) I should allocate my dirent on the heap (with some extra buffer
> space) rather than the stack, because if dirent has a "char d_name[]"
> rather than a "char d_name[BIG_ENOUGH]" declaration, then my
> stack-based allocation followed by writing to d_name will smash the
> stack.

Yes, or BIG_ENOUGH may not be long enough for the name you are creating.

> I'll submit a re-roll with those two things fixed.

Thanks.