[9fans] ip(2) man page: return code of parseip() and parsemaskip()

[9fans] ip(2) man page: return code of parseip() and parsemaskip()

[Gabriel Diaz]

Hello

The synopsis say:

ulong       parseip(uchar *ipaddr, char *str)
ulong       parseipmask(uchar *ipaddr, char *str)

the description:

"Parseip converts a string pointed to by str to a 16–byte IP address
starting at ipaddr. As a concession to backwards compatibility, if the
string is a V4 address, the return value is an unsigned long integer
containing the big–endian V4 address. If not, the return value is 6.
Parseipmask converts a string pointed to by str to a 6–byte IP mask
starting at ipaddr. It too returns an unsigned long big–endian V4
address or 6. Both routines return –1 on errors."

and the compiler:

warning: spf.c:226 useless or misleading comparison: ULONG < 0
warning: spf.c:227 useless or misleading comparison: ULONG < 0
warning: spf.c:230 useless or misleading comparison: ULONG < 0

Is this check correct? can one return -1 with a ulong? or i should
cast it to long? or should i check against 0xffffffff?

there is not an obvious  return -1 in /sys/src/libip/parseip.c.

i'm confused about this,  i can't found anything on group archives about this.

thanks

gabi

[9fans] Re: ip(2) man page: return code of parseip() and parsemaskip()

[Gabriel Diaz]

hello

to answer myself a bit, seems that parseip returns 0 if there is no
valid ip on str, at least if str = "pepe" :)

i would consider 0.0.0.0 as an invalid ip for the moment. should i
create a patch to the man page?

thanks

gabi


On 10/20/06, Gabriel Diaz <gabidiaz@gmail.com> wrote:
> Hello
>
> The synopsis say:
>
> ulong       parseip(uchar *ipaddr, char *str)
> ulong       parseipmask(uchar *ipaddr, char *str)
>
> the description:
>
> "Parseip converts a string pointed to by str to a 16–byte IP address
> starting at ipaddr. As a concession to backwards compatibility, if the
> string is a V4 address, the return value is an unsigned long integer
> containing the big–endian V4 address. If not, the return value is 6.
> Parseipmask converts a string pointed to by str to a 6–byte IP mask
> starting at ipaddr. It too returns an unsigned long big–endian V4
> address or 6. Both routines return –1 on errors."
>
> and the compiler:
>
> warning: spf.c:226 useless or misleading comparison: ULONG < 0
> warning: spf.c:227 useless or misleading comparison: ULONG < 0
> warning: spf.c:230 useless or misleading comparison: ULONG < 0
>
> Is this check correct? can one return -1 with a ulong? or i should
> cast it to long? or should i check against 0xffffffff?
>
> there is not an obvious  return -1 in /sys/src/libip/parseip.c.
>
> i'm confused about this,  i can't found anything on group archives about this.
>
> thanks
>
> gabi
>

Re: [9fans] Re: ip(2) man page: return code of parseip() and parsemaskip()

[erik quanstrom]

the man page doesn't appear to be correct ~0UL (i.e. -1) won't be 
returned unless the address given is 255.255.255.255.

the code also does not appear to recognize ::ffff:192.168.0.1 
or ::0.0:ffff:192.168.0.1 as an ip4 address.  perhaps it's returning
6 if it was entered in the ip6 style, but that doesn't seem that useful.

perhaps the line with

	if(ip4)

should be

	if(ip4 || memcmp(to, v4prefix, IPaddrlen-IPv4addrlen) == 0)

- erik

Re: [9fans] Re: ip(2) man page: return code of parseip() and parsemaskip()

[Russ Cox]

The man page lies.  There is no way to tell using
those functions whether you have parsed a valid
address.

::ffff:192.168.0.1 is *not* an IPv4 address, syntactically.
IPv4 addresses don't have colons and hexadecimal in them.

It may be an IPv6 address that is semantically equivalent
to an IPv4 address, but parseip is just a poor little parser.

Russ

Re: [9fans] Re: ip(2) man page: return code of parseip() and parsemaskip()

[erik quanstrom]

i isn't that what i said?

but i think it's silly to differentiate between 192.168.0.1 and
::ffff:192.168.0.1 an ip6 address. that's like a c compiler declaring
0x3 != 3.

it's not a hard fix, can we just do it?

- erik

On Fri Oct 20 09:45:25 EDT 2006, rsc@swtch.com wrote:
> ::ffff:192.168.0.1 is *not* an IPv4 address, syntactically.
> IPv4 addresses don't have colons and hexadecimal in them.
> 
> It may be an IPv6 address that is semantically equivalent
> to an IPv4 address, but parseip is just a poor little parser.
> 
> Russ

Re: [9fans] Re: ip(2) man page: return code of parseip() and parsemaskip()

[Russ Cox]

> but i think it's silly to differentiate between 192.168.0.1 and
> ::ffff:192.168.0.1 an ip6 address. that's like a c compiler declaring
> 0x3 != 3.

No, it's not.  It's like if atoi, in addition to returning
the actual value, also returned the base the number
was written in.  Most callers wouldn't care, but some
might.

Most people calling parseip shouldn't care what
format the address was in, and should use *to
as the address.  The only interesting question
that should ever be asked of the return value is whether
or not it is equal to 6.  In particular, code that uses

   ip = parseip(to, from);

and then goes on to use ip as an IP address
is wrong and needs to be rewritten, not catered to.

Russ

Re: [9fans] Re: ip(2) man page: return code of parseip() and parsemaskip()

[erik quanstrom]

On Fri Oct 20 11:09:54 EDT 2006, rsc@swtch.com wrote:
> > but i think it's silly to differentiate between 192.168.0.1 and
> > ::ffff:192.168.0.1 an ip6 address. that's like a c compiler declaring
> > 0x3 != 3.
> 
> No, it's not.  It's like if atoi, in addition to returning
> the actual value, also returned the base the number
> was written in.  Most callers wouldn't care, but some
> might.

but it's instructive that atoi does not.

i think point of libip is to hide this stuff.
do you have an example of code where it would
be beneficial to distinguish ::ffff:192.168.0.1 from
192.168.0.1?

> Most people calling parseip shouldn't care what
> format the address was in, and should use *to
> as the address.  The only interesting question
> that should ever be asked of the return value is whether
> or not it is equal to 6.  In particular, code that uses
> 
>    ip = parseip(to, from);
> 
> and then goes on to use ip as an IP address
> is wrong and needs to be rewritten, not catered to.

however, if you decide that you don't have an ip4
address based on the fact that parseip returns 6,
you are also wrong.  

i think it would be more useful to know if it is
an ip4 address rather than what format it was
entered in.

just my opinion.

- erik