RFR(XS): 8202181: Correctly specify size of hostname buffer in Unix Inet*AddressImpl_getLocalHostName implementations

vyom tewari vyom.tewari at oracle.com
Fri Apr 27 03:57:33 UTC 2018


Hi Christoph,


On Tuesday 24 April 2018 04:45 PM, Langer, Christoph wrote:
> Hi Vyom,
>
>> I think, it is intentional to handle case where return "hostname" is to large to
>> fit in  array.  if you see the man page(http://man7.org/linux/man-
>> pages/man2/gethostname.2.html) it says that it is unspecified whether
>> returned buffer includes a terminating null byte.
>>
>> current code will put null in case of large "hostname", What do you think ?
> yes, I had read the man page and saw this point of the spec. But exactly for this purpose there's this code:
>
> // make sure string is null-terminated
> hostname[NI_MAXHOST] = '\0';
>
> If we only hand 'NI_MAXHOST' as size value into gethostname, then the function might only write NI_MAXHOST - 1 characters of the hostname into the buffer.
doc says it will copy len bytes into buffer and will not copy null 
character into the buffer.

################################

*C library/kernel differences*
        The GNU C library does not employ the*gethostname*() system call;
        instead, it implements*gethostname*() as a library function that calls
        uname(2) <http://man7.org/linux/man-pages/man2/uname.2.html>  and copies up to/len/  bytes from the returned/nodename/  field
        into/name/.  Having performed the copy, the function then checks if
        the length of the/nodename/  was greater than or equal to/len/, and if
        it is, then the function returns -1 with/errno <http://man7.org/linux/man-pages/man3/errno.3.html>/  set to*ENAMETOOLONG*;
        in this case, a terminating null byte is not included in the returned
        /name/.
############################################################

Just for curiosity, are we facing any issues with the current code ?. Your code change looks logical but if nothing is broken then why to change code.

Thanks,
Vyom

>
> Best regards
> Christoph
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20180427/2b9046f5/attachment.html>


More information about the net-dev mailing list