Date: Fri, 4 Oct 2002 12:06:12 +1000 (EST) From: Ian Lister <freebsd-lists@lister.dnsalias.net> To: Leo Bicknell <bicknell@ufp.org> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: inet_aton() Bug or feature? Message-ID: <Pine.BSF.4.44.0210041203270.10833-100000@sapporo.home> In-Reply-To: <20021004013814.GA70364@ussenterprise.ufp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Oct 2002, Leo Bicknell wrote: >In a message written on Thu, Oct 03, 2002 at 12:55:15PM -0700, Crist J. Clark wrote: >> This is a feature not a bug since it is documented in inet_aton(3), >> >> 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). > >While I agree it's documented, does it agree with practice? > >The earliest reference I could find was RFC 952 >(ftp://ftp.isi.edu/in-notes/rfc952.txt): It agrees with the SUS definition of inet_addr(), and inet_aton() should probably be consistent with that: http://www.opengroup.org/onlinepubs/007904975/functions/inet_addr.html Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.44.0210041203270.10833-100000>