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