Re: [9fans] bug in v4parseip?

[Lucio De Re <lucio@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