<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Bernd,<br>
</p>
<p>Thank you for your comments! inet_addr() is POSIX.1, please see
<a class="moz-txt-link-freetext" href="https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html">https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html</a></p>
<p>In its common implementation inet_addr() is just</p>
<pre>u_long
<span class="enscript-function-name">inet_addr</span>(cp)
<span class="enscript-type">register</span> <span class="enscript-type">const</span> <span
class="enscript-type">char</span> *cp;
{
<span class="enscript-type">struct</span> in_addr val;
<span class="enscript-keyword">if</span> (inet_aton(cp, &val))
<span class="enscript-keyword">return</span> (val.s_addr);
<span class="enscript-keyword">return</span> (INADDR_NONE);
}
</pre>
<p></p>
<p>In turn, inet_aton() is what's described - it either recognizes
the hex/octal bases or relies on strtoul().<br>
</p>
<p>RFC 3493 section 6.1 specifies a protocol-independent node name
and service name translation:<br>
</p>
<pre class="newpage"> "If the specified address family is AF_INET or AF_UNSPEC,
address strings using Internet standard dot notation as specified in
inet_addr() are valid."</pre>
<p>In the discussion of .ofLiteral() it was not concluded that
.ofPosixLiteral() would be insecure or undesirable. From the
'security issues' point of view, it is a new method, it won't
change the behavior of old apps. If any code (a csrf filter)
written in Java recognized (knowing what it does) additional
literal address formats, it would only be an improvement (in
detection). The good reason is bringing compatibility with
standard tools relying on inet_addr() into Java, that would
actually help overcoming the confusion between the standards. A
real world example could be a Java program parsing HOSTS file (it
allows hexadecimal address segments).<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">Am 26.03.24 um 20:10 schrieb Bernd
Eckenfels:<br>
</div>
<blockquote type="cite"
cite="mid:20240326191031.A4185661192@dd33810.kasserver.com">
<pre class="moz-quote-pre" wrap="">Would be helpful to point to the posix standard/requirement which mandates this. Do you mean a single Unix api description or a posix command spec? I don’t think I know of any such things.
Wikipedia claims A POSIX-conforming variant of inet_aton, the inet_pton() function, supports only the four-decimal variant of IP addresses.[10]
And can you also justify a bit more who needs that octal compatibility? Over the years a lot of confusion (zero padding) and security issues (csrf filters not catching all formats) have been found, so it’s really not a good idea to implement it for no good reason. I think this was also the conclusion for the ofLiteral() api.
Sergey Chernyshev wrote on 26. Mar 2024 17:51 (GMT +01:00):
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hello Core Libs Dev team,
I would like to propose a PR to extend the InetAddress API in JDK 23,
</pre>
</blockquote>
</blockquote>
</body>
</html>