Re: fdopendir: Fix fd leak and test failure on native Windows

[Bruno Haible]

KO Myung-Hun wrote:
> > dirfd is specified at
> > https://pubs.opengroup.org/onlinepubs/9699919799/functions/dirfd.html
> > Which says that if "The dirp argument does not refer to a valid directory 
> > stream"
> > the function may fail with error EINVAL. It may alternatively simply crash
> > ("the behavior is undefined").
> 
> Then, gnulib decided to crash instead of returning -1 with setting errno
> to EINAL if dir_p has the garbage value which is not returned by opendir() ?

Correct.

If a function that takes a pointer as argument wants to reject all invalid
values reliably, without crashing, the only possible implementation is one
that keeps a list of the valid values. This uses O(N) of space and — unless
hashing or a binary tree is used — O(N) of time per operation. Therefore
in these cases POSIX does not require this sort of behaviour, but makes
it optional:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/dirfd.html
https://pubs.opengroup.org/onlinepubs/9699919799/functions/closedir.html
https://pubs.opengroup.org/onlinepubs/9699919799/functions/dbm_close.html
https://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv_close.html
https://pubs.opengroup.org/onlinepubs/9699919799/functions/pclose.html
https://pubs.opengroup.org/onlinepubs/9699919799/functions/sem_close.html

It is only mandatory here:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/dlclose.html

Gnulib's goal is that correct programs that use POSIX functions run fine
also on native Windows, kLIBC, etc. It is not a goal to make the Gnulib
replacement functions be "safer" in the sense that they will detect
programming problems better than glibc does. We assume that the application
development happens on glibc systems and that the debugging facilities
(valgrind, ltrace, strace, etc.) there are sufficient; then the application
will not have such logic mistakes.

Bruno