public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Ulrich Drepper <drepper@redhat.com>
Cc: Glibc hackers <libc-hacker@sources.redhat.com>
Subject: [PATCH] Make inet_pton RFC2133 compliant
Date: Wed, 04 Aug 2004 10:13:00 -0000	[thread overview]
Message-ID: <20040804075653.GE30497@sunsite.ms.mff.cuni.cz> (raw)

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  <jakub@redhat.com>

	* resolv/inet_pton.c (inet_pton4): Disallow octal numbers.  Reported
	by A. Guru <a.guru@sympatico.ca>.  [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

             reply	other threads:[~2004-08-04 10:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-04 10:13 Jakub Jelinek [this message]
2004-08-05 16:28 ` Ulrich Drepper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040804075653.GE30497@sunsite.ms.mff.cuni.cz \
    --to=jakub@redhat.com \
    --cc=drepper@redhat.com \
    --cc=libc-hacker@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).