apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: cvs commit: apr/network_io/unix sockaddr.c
Date Fri, 25 Jun 2004 14:11:45 GMT
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

Mime
View raw message