I ran into this myself just now...
While we could, of course, disable the warning, I wonder if this is the
right way to go. It seems to be deprecated for good reasons. See the
readdir_r man page:
http://man7.org/linux/man-pages/man3/readdir_r.3.html
I quote:
It is recommended that applications usereaddir(3)
<http://man7.org/linux/man-pages/man3/readdir.3.html> instead of
*readdir_r*(). Furthermore, since version 2.24, glibc deprecates
*readdir_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 directory 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)
<http://man7.org/linux/man-pages/man3/readdir.3.html> is
not required to be thread-safe. However, in modern
implementations (including the glibc implementation), concurrent
calls toreaddir(3)
<http://man7.org/linux/man-pages/man3/readdir.3.html> that specify different
directory streams are
thread-safe. Therefore, the use of*readdir_r*() is generally
unnecessary in multithreaded programs. In cases where multiple
threads must read from the same directory stream, usingreaddir(3)
<http://man7.org/linux/man-pages/man3/readdir.3.html>
with external synchronization is still preferable to the use of
*readdir_r*(), for the reasons given in the points above.
* It is expected that a future version of POSIX.1 will make
*readdir_r*() obsolete, and require thatreaddir(3)
<http://man7.org/linux/man-pages/man3/readdir.3.html> be thread-safe
when concurrently employed on different directory streams.
/Magnus
On 2018-03-12 08:45, Thomas Stüfe wrote:
Thanks a lot for digging this up! That may very well be.
I see that we locally disable the warning in os_linux.inline.hpp. My error
happens when compiling the jdk, among others TimeZone_md.c. I do not see
that we pass -Wdeprecated-declarations.
I am still unsure whether this is a new issue or an existing one I
uncovered in by environment. Unfortunately I have to drive to the office
now and will then be back in gcc 4.8 land. Have to pick this up again next
weekend (or just install a saner Linux).
Thank you!
Thomas
On Mon, Mar 12, 2018 at 8:26 AM, David Holmes <david.hol...@oracle.com>
wrote:
We already dealt with this in the VM:
http://hg.openjdk.java.net/jdk10/master/rev/f5f2a2d13775
by disabling the warning.
That suggests to me that this warning must have been disabled in the JDK
build too. So perhaps recent flag reworking has modified that. ??
David
On 12/03/2018 5:15 PM, David Holmes wrote:
Hi Thomas,
On 12/03/2018 5:02 PM, Thomas Stüfe wrote:
Hi all,
maybe someone has an idea:
I build on a freshly installed Linux instance (MX17), using gcc 6.3.0.
I get this error:
Creating support/modules_cmds/jdk.pack/unpack200 from 7 file(s)
/shared/projects/openjdk/jdk-hs/source/src/jdk.management/un
ix/native/libmanagement_ext/OperatingSystemImpl.c:
In function ‘read_dir’:
/shared/projects/openjdk/jdk-hs/source/src/jdk.management/un
ix/native/libmanagement_ext/OperatingSystemImpl.c:83:5:
warning: ‘readdir_r’ is deprecated [-Wdeprecated-declarations]
if (readdir_r(dirp, entry, &p) == 0) {
^~
In file included from
/shared/projects/openjdk/jdk-hs/source/src/hotspot/os/posix/include/jvm_md.h:34:0,
from
/shared/projects/openjdk/jdk-hs/source/src/hotspot/share/include/jvm.h:32,
from
/shared/projects/openjdk/jdk-hs/source/src/jdk.management/un
ix/native/libmanagement_ext/OperatingSystemImpl.c:29:
/usr/include/dirent.h:183:12: note: declared here
extern int readdir_r (DIR *__restrict __dirp,
^~~~~~~~~
I digged and was not able to pin it to any recent change. I also think I
never successfully built on this box, so it may be my environment.
Could it be that my gcc is too new?
We've built with gcc 7 so it can't be that on its own. May be a
combination of gcc and glibc version. It was deprecated in glibc 2.24.
David
Thanks! Thomas
