Hi Paul,
> + readdir_r: now obsolescent
> + * doc/posix-functions/readdir_r.texi (readdir_r): Now obsolescent.
> --- a/doc/posix-functions/readdir_r.texi
> +++ b/doc/posix-functions/readdir_r.texi
> @@ -9,6 +9,9 @@ Gnulib module: extensions
> Portability problems fixed by Gnulib:
> @itemize
> @item
> +This function is planned to be removed from POSIX and to be deprecated
> +in glibc. Portable applications should use @code{readdir}.
I understand that this came about because of [1] and [2]. But:
What should applications (based on gnulib) use that want to read the
contents of a directory in a portable AND multithread-safe way?
Citing POSIX:2008 [3]:
"The readdir() function need not be thread-safe."
Citing Austin Group #696 [4]:
"Since the new implementation requirements for opendir( ) and closedir( ) have
the net effect of making readdir( ) thread safe, readdir_r( ) is being marked
OBSOLESCENT as superfluous."
Can we assume that all readdir() implementations supported by gnulib are
actually multithread-safe because the pointer they return is in the area
allocated by opendir() [as opposed to a static location]?
A test program could be something like
============================================================
#include <dirent.h>
#include <stdio.h>
int
main ()
{
DIR *dir1 = opendir (".");
struct dirent *d1 = readdir (dir1);
DIR *dir2 = opendir (".");
DIR *dir3 = opendir (".");
struct dirent *d2 = readdir (dir2);
struct dirent *d3 = readdir (dir3);
return (d1 == d2 || d1 == d3 || d2 == d3);
}
============================================================
Bruno
[1] https://womble.decadent.org.uk/readdir_r-advisory.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=995839
[3] http://pubs.opengroup.org/onlinepubs/9699919799/functions/readdir.html
[4] http://austingroupbugs.net/view.php?id=696
