In perl.git, the branch blead-next has been updated

<http://perl5.git.perl.org/perl.git/commitdiff/49d3d70c8f638244261cb3f4586247545b495dc8?hp=7a66ad52515a09c8957c88804fdb4a961ba15df4>

- Log -----------------------------------------------------------------
commit 49d3d70c8f638244261cb3f4586247545b495dc8
Author: H.Merijn Brand <[email protected]>
Date:   Thu May 11 16:47:45 2017 +0200

    Disable readdir_r and readdir64_r on glibc >= 2.24
    
    DESCRIPTION
           This function is deprecated; use readdir(3) instead.
    
           The  readdir_r()  function was invented as a reentrant version of 
read-
           dir(3).  It reads the next directory entry from  the  directory  
stream
           dirp,  and  returns  it  in  the  caller-allocated buffer pointed to 
by
           entry.  For details of the dirent structure, see readdir(3).
    
           A pointer to the returned buffer is placed in *result; if  the  end  
of
           the  directory stream was encountered, then NULL is instead returned 
in
           *result.
    
           It is recommended that applications use  readdir(3)  instead  of  
read-
           dir_r().   Furthermore,  since  version  2.24,  glibc  deprecates 
read-
           dir_r().  The reasons are as follows:
    
           *  On systems where NAME_MAX is undefined, calling readdir_r()  may  
be
              unsafe  because  the  interface does not allow the caller to 
specify
              the length of the buffer used for the returned directory entry.
    
           *  On some systems, readdir_r() can't read directory entries with  
very
              long  names.   When the glibc implementation encounters such a 
name,
              readdir_r() fails with the error ENAMETOOLONG after the final 
direc-
              tory  entry  has  been read.  On some other systems, readdir_r() 
may
              return a success status, but the returned d_name field  may  not  
be
              null terminated or may be truncated.
    
           *  In  the  current POSIX.1 specification (POSIX.1-2008), readdir(3) 
is
              not required to be thread-safe.  However, in modern  
implementations
              (including the glibc implementation), concurrent calls to 
readdir(3)
              that specify different directory streams  are  thread-safe.   
There-
              fore,  the  use  of  readdir_r()  is generally unnecessary in 
multi-
              threaded programs.  In cases where multiple threads must  read  
from
              the  same  directory stream, using readdir(3) with external 
synchro-
              nization is still preferable to the use of readdir_r(), for the 
rea-
              sons given in the points above.
    
           *  It  is  expected  that  a  future version of POSIX.1 will make 
read-
              dir_r() obsolete, and require that readdir(3)  be  thread-safe  
when
              concurrently employed on different directory streams.
-----------------------------------------------------------------------

Summary of changes:
 reentr.h        | 5 +++++
 regen/reentr.pl | 5 +++++
 2 files changed, 10 insertions(+)

diff --git a/reentr.h b/reentr.h
index c268851922..b1f3c80615 100644
--- a/reentr.h
+++ b/reentr.h
@@ -56,6 +56,11 @@
 #   define NETDB_R_OBSOLETE
 #endif
 
+#if defined(__GLIBC__) && (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ 
>= 24))
+#   undef HAS_READDIR_R
+#   undef HAS_READDIR64_R
+#endif
+
 /*
  * As of OpenBSD 3.7, reentrant functions are now working, they just are
  * incompatible with everyone else.  To make OpenBSD happy, we have to
diff --git a/regen/reentr.pl b/regen/reentr.pl
index f8f78a5152..b73193ce56 100644
--- a/regen/reentr.pl
+++ b/regen/reentr.pl
@@ -106,6 +106,11 @@ print $h <<EOF;
 #   define NETDB_R_OBSOLETE
 #endif
 
+#if defined(__GLIBC__) && (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ 
>= 24))
+#   undef HAS_READDIR_R
+#   undef HAS_READDIR64_R
+#endif
+
 /*
  * As of OpenBSD 3.7, reentrant functions are now working, they just are
  * incompatible with everyone else.  To make OpenBSD happy, we have to

--
Perl5 Master Repository

Reply via email to