[PATCH] readdir_r: now obsolescent

[PATCH] readdir_r: now obsolescent

[Paul Eggert]

* doc/posix-functions/readdir_r.texi (readdir_r): Now obsolescent.
* lib/mountlist.c (read_file_system_list): Add a FIXME.
---
 ChangeLog                          | 6 ++++++
 doc/posix-functions/readdir_r.texi | 3 +++
 lib/mountlist.c                    | 2 ++
 3 files changed, 11 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 5e47384..40bdd23 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2016-02-08  Paul Eggert  <eggert@cs.ucla.edu>
+
+	readdir_r: now obsolescent
+	* doc/posix-functions/readdir_r.texi (readdir_r): Now obsolescent.
+	* lib/mountlist.c (read_file_system_list): Add a FIXME.
+
 2016-02-06  Paul Eggert  <eggert@cs.ucla.edu>
 
 	misc: port better to gcc -fsanitize=address
diff --git a/doc/posix-functions/readdir_r.texi b/doc/posix-functions/readdir_r.texi
index 0eac1c3..d3512c3 100644
--- 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}.
+@item
 This function has an incompatible declaration on some platforms:
 Solaris 11 2011-11 (when @code{_POSIX_PTHREAD_SEMANTICS} is not defined).
 @end itemize
diff --git a/lib/mountlist.c b/lib/mountlist.c
index 1e592d2..829b31d 100644
--- a/lib/mountlist.c
+++ b/lib/mountlist.c
@@ -1068,6 +1068,8 @@ read_file_system_list (bool need_fs_type)
         struct dirent entry;
         struct dirent *result;
 
+        /* FIXME: readdir_r is planned to be withdrawn from POSIX and
+           marked obsolescent in glibc.  Use readdir instead.  */
         if (readdir_r (dirp, &entry, &result) || result == NULL)
           break;
 
-- 
2.5.0

Re: [PATCH] readdir_r: now obsolescent

[Bruno Haible]

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

Re: [PATCH] readdir_r: now obsolescent

[Paul Eggert]

On 02/10/2016 05:31 PM, Bruno Haible wrote:
> 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]?

That was my assumption, yes. It wouldn't hurt to add a test for this.