Re: [PATCH v2 4/9] linux: Use getdents64 on non-LFS readdir

[Florian Weimer <fweimer@redhat.com>]

* Adhemerval Zanella via Libc-alpha:

> ENAMETOOLONG does make more sense, I have fixed it locally.  I am not
> sure I understood by 'delayed', it it report on the readdir call, but
> the next entry will still be reported in the next readdir call.  The
> construction such as won't work:
>
>   while (readdir (dp) != NULL)
>     {
>       [...]
>     }
>
> But this will work as intended:
>
>   while (1)
>     {
>       errno = 0;
>       struct dirent *entry = readdir (dp);
>       if (entry == NULL)
> 	{
> 	  if (errno == ENAMETOOLONG)
> 	    continue;
> 	  break;
> 	}
>     }

I think it's unreasonable to expect that this pattern will work.  It
assumes that readdir updates dp despite the error.  In other
implementations, this may produce an endless loop.  This is why for
readdir_r, we record the ENAMETOOLONG error as pending, and report it
only at the end.  (We should do the same for EOVERFLOW errors.)

> Even if go to buffer resize, application will still need to handle
> ENOMEM so I am not sure if using separated buffer is really an
> improvement here (at least on trying to adequate usual way to call
> opendir functions).

ENOMEM is a temporary error, ENAMETOOLONG depends on file system content
and may be much more difficult to resolve.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill