From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19156 invoked by alias); 4 Aug 2004 10:13:41 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 19134 invoked from network); 4 Aug 2004 10:13:37 -0000 Received: from unknown (HELO sunsite.ms.mff.cuni.cz) (195.113.15.26) by sourceware.org with SMTP; 4 Aug 2004 10:13:37 -0000 Received: from sunsite.ms.mff.cuni.cz (sunsite.mff.cuni.cz [127.0.0.1]) by sunsite.ms.mff.cuni.cz (8.12.8/8.12.8) with ESMTP id i747us3j032632; Wed, 4 Aug 2004 09:56:54 +0200 Received: (from jakub@localhost) by sunsite.ms.mff.cuni.cz (8.12.8/8.12.8/Submit) id i747usV8032630; Wed, 4 Aug 2004 09:56:54 +0200 Date: Wed, 04 Aug 2004 10:13:00 -0000 From: Jakub Jelinek To: Ulrich Drepper Cc: Glibc hackers Subject: [PATCH] Make inet_pton RFC2133 compliant Message-ID: <20040804075653.GE30497@sunsite.ms.mff.cuni.cz> Reply-To: Jakub Jelinek Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-SW-Source: 2004-08/txt/msg00003.txt.bz2 Hi! http://www.faqs.org/rfcs/rfc2133.html is a little bit vague, but still: Inet_pton() returns 1 if the conversion succeeds, 0 if the input is not a valid IPv4 dotted-decimal string ... If the af argument is AF_INET, the function accepts a string in the standard IPv4 dotted-decimal form: ddd.ddd.ddd.ddd where ddd is a one to three digit decimal number between 0 and 255. Note that many implementations of the existing inet_addr() and inet_aton() functions accept nonstandard input: octal numbers, hexadecimal numbers, and fewer than four numbers. inet_pton() does not accept these formats. Both inet_aton and inet_pton ATM parse octal numbers, but interpret them a different way, which is certainly a bad thing: inet_aton ("035.000.00000.071", &in) inet_pton (AF_INET, "035.000.00000.071", &in) Both calls succeed (return 1), but the first one fills in 29.0.0.57 while the second one 35.0.0.71. I've googled around what other inet_pton4 implementations do. Some do what glibc does ATM, some do what the following patch does, BSD ones forbid if first digit in the octet is '0' and second character is digit, but not '9' (which is really strange, why is 091 special while 085 not). The patch below disallows all octal literals with the exception of 0, i.e. disallows even 00 or 0000000000. I'm not sure if it should allow that or not (similarly there is no ambiguity with inet_aton for say 07 or 006). 2004-08-04 Jakub Jelinek * resolv/inet_pton.c (inet_pton4): Disallow octal numbers. Reported by A. Guru . [BZ #295] --- libc/resolv/inet_pton.c.jj 2002-08-03 14:08:47.000000000 +0200 +++ libc/resolv/inet_pton.c 2004-08-04 11:55:12.826244037 +0200 @@ -69,7 +69,8 @@ libc_hidden_def (inet_pton) /* int * inet_pton4(src, dst) - * like inet_aton() but without all the hexadecimal and shorthand. + * like inet_aton() but without all the hexadecimal, octal (with the + * exception of 0) and shorthand. * return: * 1 if `src' is a valid dotted quad, else 0. * notice: @@ -94,6 +95,8 @@ inet_pton4(src, dst) if (ch >= '0' && ch <= '9') { u_int new = *tp * 10 + (ch - '0'); + if (saw_digit && *tp == 0) + return (0); if (new > 255) return (0); *tp = new; Jakub