I agree with Albrecht that ENOENT is an error condition (with a different meaning than "end of directory").

This is documented for SUSv2 from the last century:
https://pubs.opengroup.org/onlinepubs/007908799/xsh/readdir.html

| When the end of the directory is encountered, a null pointer is returned and errno is not changed.

and for modern POSIX:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/readdir.html

| When the end of the directory is encountered, a null pointer shall be returned and errno is not changed.

FLTK sets errno to zero and therefore errno must be zero after the readdir() call for "end of directory".

The FLTK function readentry() will return 0 for "end of directory" and -1 for ENOENT.
For the latter case the FLTK function fl_scandir() will abort its loop and return -1 and ENOENT.
This is the intended behaviour in general and I vote against changing it for an unsupported
non-POSIX platform (it is documented that a POSIX conformant readdir() is required).
If readdir() is broken on such a platform, a POSIX conformant readdir() replacement
or a separate implementation for scandir(), e.g. in "scandir_dos.c", should be provided.

If we agree that ENOENT indicates an error:
Directly passing ENOENT through fl_scandir() back to the caller maybe is questionable,
because strictly speaking ENOENT has a different meaning for scandir():
https://pubs.opengroup.org/onlinepubs/9699919799/functions/scandir.html
But it looks like that mapping ENOENT to one of the other error codes would not match better.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.