JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

[Langer, Christoph]

Hi Gary,

ok, I would agree that a change like globally moving from dbgSysInetAddr to something like dbgsysPToN should at least be handled by a different change.

Best regards
Christoph

From: Gary Adams [mailto:gary.adams at oracle.com]
Sent: Montag, 5. Februar 2018 20:15
To: gary.adams at oracle.com
Cc: Langer, Christoph <christoph.langer at sap.com>; OpenJDK Serviceability <serviceability-dev at openjdk.java.net>; OpenJDK Build <build-dev at openjdk.java.net>; OpenJDK Networking <net-dev at openjdk.java.net>
Subject: Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

One more to fix to cover the remaining test failures I was seeing.

Previously, using inet_addr, there was a single -1 return that needed to be checked.
Now that we're using inet_pton, there is a -1 and a 0 error return to be considered.

My preference would be to leave the dbgSysInetAddr name unchanged and have the low level
check for inet_pton errors to simply return the -1 that was previously checked.

This specific issue is about the deprecation of library functions on windows. I'd recommend not
upgrading the other platforms at this time until a complete update is done for ipv6 support.

I'll post a new webrev when I've retested using the updated inet_pton error checking.

...


Hi Gary,





> Here's a revised webrev

>

>    http://cr.openjdk.java.net/~gadams/8080990/webrev.01/index.html<http://cr.openjdk.java.net/%7Egadams/8080990/webrev.01/index.html>

>

> Still testing ...

>

> Using shutdown() fixed problems reported by the

> java/nio/channelSocketChannel tests.



The fix looks good. I would think we should rename dbgsysInetAddr to dbgsysPToN and use inet_pton also for the Unix/Linux platforms. It would be the better choice there as well, though we still only support IPv4 in libdt_socket.



>

> I also noticed prior use of getaddrinfo for "localhost" was not calling

> freeaddrinfo.



Thanks for spotting/fixing that.



Best regards

Christoph