From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <713e94f597696a29dd5a3ef441a109ca@plan9.bell-labs.com>
From: David Presotto <presotto@closedmind.org>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] bug in v4parseip?
In-Reply-To: <6d3220b4.0302121654.66a0f55e@posting.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Thu, 13 Feb 2003 10:21:09 -0500
Topicbox-Message-UUID: 5bdf3fd4-eacb-11e9-9e20-41e7f4b1d025

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.