You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Joe Orton <jo...@redhat.com> on 2004/06/25 16:11:45 UTC
Re: cvs commit: apr/network_io/unix sockaddr.c
On Fri, Jun 25, 2004 at 01:51:46PM -0000, martin@apache.org wrote:
> --- sockaddr.c 1 Jun 2004 19:50:14 -0000 1.52
> +++ sockaddr.c 25 Jun 2004 13:51:46 -0000 1.53
> @@ -767,6 +767,19 @@
> if (shift < 0) {
> return APR_EBADIP;
> }
> +/*@@@ WARNING: BEWARE:
<insert rant about putting bugs in bug databases>
> +The man page for inet_pton()/inet_aton() et.al. says:
> + All numbers supplied as ``parts'' in a `.' notation may be decimal,
> + octal, or hexadecimal, as specified in the C language (i.e., a leading 0x
> + or 0X implies hexadecimal; otherwise, a leading 0 implies octal; other-
> + wise, the number is interpreted as decimal).
> +OTOH, "man atoi" says:
> + The atoi() function [...] is equivalent to:
> + (int)strtol(nptr, (char **)NULL, 10);
> +which forces interpretation as _decimal_. As a result, this routine will
> +interpret a string 0177.0000.0000.0001 as 177.0.0.1, while inet_pton()
> +will interpret it as 127.0.0.1!
> +@@@*/
inet_pton() is not required to do that, or even "is required not to.
What issue did you encounter?
http://www.opengroup.org/onlinepubs/009695399/functions/inet_ntop.html
"The inet_pton() function does not accept other formats (such as the
octal numbers, hexadecimal numbers, and fewer than four numbers that
inet_addr() accepts)."
joe