* [9fans] bug in v4parseip? @ 2003-02-13 9:38 Saroj Mahapatra 2003-02-13 15:21 ` David Presotto 0 siblings, 1 reply; 6+ messages in thread From: Saroj Mahapatra @ 2003-02-13 9:38 UTC (permalink / raw) To: 9fans v4parseip function code in libip/ipparse.c looks suspicious. First of all, I don't know why it bothers about class A or B given the trend towards classless addresses? Next, if it is trying to handle inputs of the form: a.b.c and a.b, then the problem is that c in the first case can be a 24-bit integer and b in the second case can be a 16-bit integer; the code assigns those parts to a 'uchar' resulting in truncation. Or, did I misunderstand the code? Thank you, Saroj Mahapatra ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] bug in v4parseip? 2003-02-13 9:38 [9fans] bug in v4parseip? Saroj Mahapatra @ 2003-02-13 15:21 ` David Presotto 2003-02-13 15:55 ` Lucio De Re 0 siblings, 1 reply; 6+ messages in thread From: David Presotto @ 2003-02-13 15:21 UTC (permalink / raw) To: 9fans On Thu Feb 13 04:50:37 EST 2003, saroj@optonline.net wrote: > v4parseip function code in libip/ipparse.c looks suspicious. First of > all, I don't know why it bothers about class A or B given the trend > towards classless addresses? Classless or not, the most standard string form of v4 IP addresss is a set of dot separated decimal numbers, each number representing an octet. The only truncated form was the class{ABC} one and such truncated addresses (such as 127.1) are still very common. Ignoring them would be a disservice. Hence the class sensitivity. > Next, if it is trying to handle inputs of > the form: a.b.c and a.b, then the problem is that c in the first case > can be a 24-bit integer and b in the second case can be a 16-bit > integer; the code assigns those parts to a 'uchar' resulting in > truncation. Or, did I misunderstand the code? In the (classy?) truncated forms a, b, and c are still required to be octet representations. You understood the code, just not 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 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] bug in v4parseip? 2003-02-13 15:21 ` David Presotto @ 2003-02-13 15:55 ` Lucio De Re 2003-02-13 16:12 ` David Presotto 0 siblings, 1 reply; 6+ messages in thread From: Lucio De Re @ 2003-02-13 15:55 UTC (permalink / raw) To: 9fans 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 <grin> > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] bug in v4parseip? 2003-02-13 15:55 ` Lucio De Re @ 2003-02-13 16:12 ` David Presotto 2003-02-13 16:17 ` Boyd Roberts 2003-02-13 16:29 ` Lucio De Re 0 siblings, 2 replies; 6+ messages in thread From: David Presotto @ 2003-02-13 16:12 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 116 bytes --] that still doesn't give me a definition. I guess the implied definition is do whatever BSD is doing at the moment? [-- Attachment #2: Type: message/rfc822, Size: 4122 bytes --] From: Lucio De Re <lucio@proxima.alt.za> To: 9fans@cse.psu.edu Subject: Re: [9fans] bug in v4parseip? Date: Thu, 13 Feb 2003 17:55:43 +0200 Message-ID: <20030213175543.B9084@cackle.proxima.alt.za> 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 <grin> > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] bug in v4parseip? 2003-02-13 16:12 ` David Presotto @ 2003-02-13 16:17 ` Boyd Roberts 2003-02-13 16:29 ` Lucio De Re 1 sibling, 0 replies; 6+ messages in thread From: Boyd Roberts @ 2003-02-13 16:17 UTC (permalink / raw) To: 9fans David Presotto wrote: >that still doesn't give me a definition. I guess the implied >definition is do whatever BSD is doing at the moment? > But it's a hideously bad idea. Why go down that path at all? A dotted quad is a dotted quad and be done with it. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] bug in v4parseip? 2003-02-13 16:12 ` David Presotto 2003-02-13 16:17 ` Boyd Roberts @ 2003-02-13 16:29 ` Lucio De Re 1 sibling, 0 replies; 6+ messages in thread From: Lucio De Re @ 2003-02-13 16:29 UTC (permalink / raw) To: 9fans On Thu, Feb 13, 2003 at 11:12:25AM -0500, David Presotto wrote: > > that still doesn't give me a definition. I guess the implied > definition is do whatever BSD is doing at the moment? I was just presenting the devil's advocate position. The present code (presumably) matches the documented BSD behaviour and that ought to suffice. My guess is that only zero-insertion and elimination is permissible, going on the limited documentation. One could do worse than track BSD's behaviour, it is unlikely to fly in the face of logic. NetBSD explicitly attempts to satisfy the Posix standards unless there is good reason to avoid it. It is not very different from the Plan 9 philosophy, where Posix compatibility is just less desirable a target. Also, NetBSD retains very strong backwards compatibility, sometimes at great cost (and sometimes through lack of choice :-) so they won't have a flavour-of-the-day approach to this type of issue. ++L ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-02-13 16:29 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-02-13 9:38 [9fans] bug in v4parseip? Saroj Mahapatra 2003-02-13 15:21 ` David Presotto 2003-02-13 15:55 ` Lucio De Re 2003-02-13 16:12 ` David Presotto 2003-02-13 16:17 ` Boyd Roberts 2003-02-13 16:29 ` Lucio De Re
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 NNTP newsgroup(s).