Re: [PATCH 2/2] tools/nolibc: add support for directory access

[Thomas Weißschuh]

On 2025-02-01 11:46:59+0100, Willy Tarreau wrote:
> On Sat, Feb 01, 2025 at 11:41:58AM +0100, Thomas Weißschuh wrote:
> > On 2025-02-01 11:34:38+0100, Willy Tarreau wrote:
> > > On Thu, Jan 30, 2025 at 08:54:03PM +0100, Thomas Weißschuh wrote:
> > > > From: Thomas Weißschuh <thomas.weissschuh@xxxxxxxxxxxxx>
> > > > 
> > > > Add an allocation-free implementation of readdir() and related
> > > > functions. The implementation is modelled after the one for FILE.
> > > 
> > > I think you'd need to mention/remind the two important points that
> > > come out of that choice, one being that DIR is a fake pointer that
> > > instead stores ~fd so that it can be turned back to a valid FD, and
> > > that subsequent readdir() calls will only work from the same file
> > > unit since it relies on a local static storage.
> > 
> > Point one is true.
> > Point two not so much. It is fine to have multiple directories open at
> > the same time. All state is kept inside the kernel.
> > Only the *current* return value is in the static buffer.
> 
> Excellent point! It also needs to be mentioned.

Unfortunately POSIX is more specific in it's definition and forbids this:

	The returned pointer, and pointers within the structure, might
	be invalidated or the structure or the storage areas might be
	overwritten by a subsequent call to readdir() on the same
	directory stream.

I see two possibilities:

Allocate one 'struct dirent' as part of DIR.
Only implement readdir_r().

While readdir_r() is deprecated (according to readdir(3) but not
readdir(3p)) this seems to be due to ABI issues, which shouldn't matter
for nolibc anyways.

Personally I would prefer readdir_r().

<snip>