Date: Thu, 27 Jun 2002 11:40:03 -0700 (PDT) From: Ian Dowse <iedowse@maths.tcd.ie> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/39896: netmask 0xffffff00 no longer works in /etc/exports Message-ID: <200206271840.g5RIe3Mg096791@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/39896; it has been noted by GNATS.
From: Ian Dowse <iedowse@maths.tcd.ie>
To: cjclark@alum.mit.edu
Cc: FreeBSD-gnats-submit@FreeBSD.ORG,
"Jin Guojun[DSD]" <j_guojun@lbl.gov>
Subject: Re: bin/39896: netmask 0xffffff00 no longer works in /etc/exports
Date: Thu, 27 Jun 2002 19:30:48 +0100
In message <20020627111801.B77359@blossom.cjclark.org>, "Crist J. Clark" writes
:
>On Thu, Jun 27, 2002 at 06:59:01PM +0100, Ian Dowse wrote:
>> I'm not sure how this could have ever worked correctly, since
>> inet_network(3) does not support hex addresses of this form.
>
>Actually, it does. The manpage says,
>
> All numbers supplied as ``parts'' in a `.' notation may be decimal,
> octal, or hexadecimal, as specified in the C language (i.e., a leading 0x
> or 0X implies hexadecimal; otherwise, a leading 0 implies octal; other-
> wise, the number is interpreted as decimal).
>
>And since it is perfectly valid to provide an internet address as a
>single "part," an address like 0xffffff00 is totally valid by these
>rules. To illustrate this, all of these are the same IP address,
Ok, but the code in inet_network() seems to disagree
...
for (val = 0, i = 0; i < n; i++) {
val <<= 8;
val |= parts[i] & 0xff;
}
return (val);
so 0xffffff00 gets converted to 0.
Ian
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206271840.g5RIe3Mg096791>