From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7e53fecd6078858c09db7ffb35383c02@plan9.bell-labs.com> From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] bug in v4parseip? In-Reply-To: <20030213175543.B9084@cackle.proxima.alt.za> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-bfwykgtbofqklccmcsfqncreyw" Date: Thu, 13 Feb 2003 11:12:25 -0500 Topicbox-Message-UUID: 5c3c3fa4-eacb-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-bfwykgtbofqklccmcsfqncreyw Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit that still doesn't give me a definition. I guess the implied definition is do whatever BSD is doing at the moment? --upas-bfwykgtbofqklccmcsfqncreyw Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Thu Feb 13 10:56:21 EST 2003 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Thu Feb 13 10:56:18 EST 2003 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.30.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id C1DD219A63; Thu, 13 Feb 2003 10:56:09 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from cackle.proxima.alt.za (cackle.proxima.alt.za [196.30.44.141]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 06AE619A28 for <9fans@cse.psu.edu>; Thu, 13 Feb 2003 10:55:47 -0500 (EST) Received: from cackle.proxima.alt.za (localhost [127.0.0.1]) by cackle.proxima.alt.za (8.12.3/8.12.3) with ESMTP id h1DFtimt022532 for <9fans@cse.psu.edu>; Thu, 13 Feb 2003 17:55:45 +0200 (SAST) Received: (from lucio@localhost) by cackle.proxima.alt.za (8.12.3/8.12.3/Submit) id h1DFtiq2022531 for 9fans@cse.psu.edu; Thu, 13 Feb 2003 17:55:44 +0200 (SAST) From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] bug in v4parseip? Message-ID: <20030213175543.B9084@cackle.proxima.alt.za> Mail-Followup-To: 9fans@cse.psu.edu References: <6d3220b4.0302121654.66a0f55e@posting.google.com> <713e94f597696a29dd5a3ef441a109ca@plan9.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <713e94f597696a29dd5a3ef441a109ca@plan9.bell-labs.com>; from David Presotto on Thu, Feb 13, 2003 at 10:21:09AM -0500 Organization: Proxima Research & Development Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu X-Reply-To: lucio@proxima.alt.za List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Thu, 13 Feb 2003 17:55:43 +0200 On Thu, Feb 13, 2003 at 10:21:09AM -0500, David Presotto wrote: > > In the (classy?) truncated forms a, b, and c are still required Classful > to be octet representations. You understood the code, just not Not to my knowledge, although there probably isn't an RFC to cover it. I assume that class A addresses take exactly two values (127.1 or 10.100000) and B addresses allow three values (168.210.45000, say) as alternatives to the more conventional dot-quad. > the representation. If you do indeed use 10.100000, you won't > get what you want. I've never seen that form defined and am > not totally sure what the correct value would be, though BSD > would convert it to 10.1.134.160 which is the result I would > have guessed at. What should 192.100000.1 be? If there 192.100000.1 is invalid, a class C address should not be representable in less than four octets. The big clue is in the man page for the Unix 'route' command: For example, 128.32 is interpreted as -host 128.0.0.32; 128.32.130 is in- terpreted as -host 128.32.0.130; -net 128.32 is interpreted as 128.32.0.0; and -net 128.32.130 is interpreted as 128.32.130.0. I haven't access to Xenix, where route had no mechanism to select between hosts and nets and the description was more appropriate than the above. I do note that the above contradicts my belief that two values only apply to class A, three to class B and four to class C, but it does indicate, vaguely, that 192.100000.1 is inappropriate. You may have a point that only octets (0-255) are permitted, though. On the other hand, is it a BSDism that allows spammers to specify 32-bit addresses in URLs? > really is a well accepted definition of what non > octet representations yield, I'ld be happy to implement > that. If its a side effect of the BSD conversion, I'ld > be less thrilled. I think this type of class consciousness is disappearing from NetBSD, at least. I think even 127.1 is no longer treated sensibly in some of the library functions. 0.0.0.0, incidentally, seems no longer to mean 127.0.0.1, either. It's laziness, I think, although CIDR does justify it. ++L --upas-bfwykgtbofqklccmcsfqncreyw--