Re: jdk build fails due to "warning: ‘readdir_r’ is deprecated"

[David Holmes]

On 5/04/2018 11:05 PM, Magnus Ihse Bursie wrote:
> 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:

Sure, but "generally unnecessary in multithreaded programs" doesn't 
quite cut it when it comes to correctness. So we have a couple of 
obscure cases where readdir_r may do the wrong thing and we have a 
subset of cases where readdir may be thread-safe "enough"; and hopefully 
one day POSIX will specify it as thread-safe and all will be well in world.

Until such time as that happens IMHO we stick with the code we that 
seems to be working perfectly fine and disable the warning.

Cheers,
David

>> 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.holmes at 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
>>>>>
>