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

[KO Myung-Hun]

Hi/2.

Bruno Haible wrote:
> 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.
> 

Ok. I've understood Gnulib's goal. Thanks for your explanation.

I'll try to modify kLIBC codes.

-- 
KO Myung-Hun

Korean OS/2 User Community : https://www.os2.kr/