Re: Resolver doesn't like 1.2.3.04 in /etc/hosts

2005-10-27 Thread Jan Grant
On Thu, 27 Oct 2005, Mark Andrews wrote:

 
  On 2005-10-26, Mark Andrews wrote:
 Leading zeros are ambigious.  Some platforms treat them as octal
 others treat them as decimal.
  
  There is nothing ambiguous about the example provided.  (Perhaps
  it wasn't a good example, but it's always a bug if '04' is not
  correctly decoded, regardless of the numeric base in use.)
 
   You want a ambigious example?
 
   192.168.222.012

It amazed me that no RFC ever appears to have standardised this format 
(although it is alluded to in passing as being decimal in various other 
places). Eg, 1035 has:

[[[
 The RDATA section of
an A line in a master file is an Internet address expressed as four
decimal numbers separated by dots without any imbedded spaces (e.g.,
10.2.0.52 or 192.0.5.6).
]]]

(although that's DNS zone file format, not /etc/hosts.)

   It's much easier to just reject octal and hexadecimal than
   to work out when and when not it is ambigious.  It is also
   better to demand all 4 octets.  It also generates less
   support complaints.

I'm happy to reject octal and hex too! Anyway, count this as one (minor) 
support gripe :-)

Thanks for your time,
jan


-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44 (0)117 3317661   http://ioctl.org/jan/
stty intr ^m
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Resolver doesn't like 1.2.3.04 in /etc/hosts

2005-10-27 Thread Paul T. Root

man inet_addr

and you'll find:

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;
otherwise, the number is interpreted as decimal).


So a leading zero means hex. Stop trying to make it look pretty.

Standards are a good thing and need to be followed.



Jan Grant wrote:

***
This message has been scanned by the InterScan for CSC-SSM and found to be free 
of known security risks.
***-***


On Thu, 27 Oct 2005, Mark Andrews wrote:



On 2005-10-26, Mark Andrews wrote:


Leading zeros are ambigious.  Some platforms treat them as octal
others treat them as decimal.


There is nothing ambiguous about the example provided.  (Perhaps
it wasn't a good example, but it's always a bug if '04' is not
correctly decoded, regardless of the numeric base in use.)


You want a ambigious example?

192.168.222.012



It amazed me that no RFC ever appears to have standardised this format 
(although it is alluded to in passing as being decimal in various other 
places). Eg, 1035 has:


[[[
 The RDATA section of
an A line in a master file is an Internet address expressed as four
decimal numbers separated by dots without any imbedded spaces (e.g.,
10.2.0.52 or 192.0.5.6).
]]]

(although that's DNS zone file format, not /etc/hosts.)



It's much easier to just reject octal and hexadecimal than
to work out when and when not it is ambigious.  It is also
better to demand all 4 octets.  It also generates less
support complaints.



I'm happy to reject octal and hex too! Anyway, count this as one (minor) 
support gripe :-)


Thanks for your time,
jan




--
   __   Paul T. Root
  /_ \  1977 MGB
 /  /||  \\
||\/ ||  _ |
||   ||   ||
 \   ||__//
  \__/

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Resolver doesn't like 1.2.3.04 in /etc/hosts

2005-10-27 Thread Jan Grant
On Thu, 27 Oct 2005, Paul T. Root wrote:

 man inet_addr
 
 and you'll find:
 
 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;
 otherwise, the number is interpreted as decimal).
 
 
 So a leading zero means hex. Stop trying to make it look pretty.
 
 Standards are a good thing and need to be followed.

I also found:

[[[
STANDARDS
 The inet_ntop() and inet_pton() functions conform to X/Open Networking
 Services Issue 5.2 (``XNS5.2'').  Note that inet_pton() does not accept
 1-, 2-, or 3-part dotted addresses; all four parts must be specified and
 are interpreted only as decimal values.  This is a narrower input set
 than that accepted by inet_aton().
]]]

on that same man page :-)

Cheers,
jan

PS. I only raised the issue in case anyone else was bitten by it (which 
is why a PR might be handy). Having fixed /etc/hosts, I don't think 
this is worth wasting more energy on.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Resolver doesn't like 1.2.3.04 in /etc/hosts

2005-10-27 Thread Paul T. Root



Jan Grant wrote:

***
This message has been scanned by the InterScan for CSC-SSM and found to be free 
of known security risks.
***-***


On Thu, 27 Oct 2005, Paul T. Root wrote:



man inet_addr

and you'll find:

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;
otherwise, the number is interpreted as decimal).


So a leading zero means hex. Stop trying to make it look pretty.

Standards are a good thing and need to be followed.



I also found:

[[[
STANDARDS
 The inet_ntop() and inet_pton() functions conform to X/Open Networking
 Services Issue 5.2 (``XNS5.2'').  Note that inet_pton() does not accept
 1-, 2-, or 3-part dotted addresses; all four parts must be specified and
 are interpreted only as decimal values.  This is a narrower input set
 than that accepted by inet_aton().
]]]

on that same man page :-)


Sure but the hosts(5) man page says that it follows inet_addr(3) spec.
Sorry, I neglected to put that little leap in.



Cheers,
jan

PS. I only raised the issue in case anyone else was bitten by it (which 
is why a PR might be handy). Having fixed /etc/hosts, I don't think 
this is worth wasting more energy on.


Yeah, you're right there.

--
   __   Paul T. Root
  /_ \  1977 MGB
 /  /||  \\
||\/ ||  _ |
||   ||   ||
 \   ||__//
  \__/

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Resolver doesn't like 1.2.3.04 in /etc/hosts

2005-10-27 Thread Jan Grant
On Thu, 27 Oct 2005, Paul T. Root wrote:

 Jan Grant wrote:
  
  On Thu, 27 Oct 2005, Paul T. Root wrote:
  
  
   man inet_addr
   
   and you'll find:
   
   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;
   otherwise, the number is interpreted as decimal).
   
   
   So a leading zero means hex. Stop trying to make it look pretty.
   
   Standards are a good thing and need to be followed.

[ STANDARDS section from the man page snipped ]

 Sure but the hosts(5) man page says that it follows inet_addr(3) spec.
 Sorry, I neglected to put that little leap in.

You're right. So, we appear to agree that either the man page for 
hosts(5) is in need of an update, or the resolver is currently not 
conforming to the described behaviour? Since

1.2.3.04foo

is currently an illegal /etc/hosts entry.

Cheers,


-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44 (0)117 3317661   http://ioctl.org/jan/
They modified their trousers secretly.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Resolver doesn't like 1.2.3.04 in /etc/hosts

2005-10-26 Thread Mark Andrews

 I don't know whether this is worth filing a PR for, but it seems the 
 resolver no longer likes leading zeroes in an IP4 address in /etc/hosts.
 The change (in 5- ) appeared sometime in the last month or two.
 
 Personally I'm inclined to view this as a regression although it's 
 simple enough to work around.

Leading zeros are ambigious.  Some platforms treat them as octal
others treat them as decimal.

Mark

 Cheers,
 jan
 
 -- 
 jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
 Tel +44 (0)117 3317661   http://ioctl.org/jan/
 Unfortunately, I have a very good idea how fast my keys are moving.
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Resolver doesn't like 1.2.3.04 in /etc/hosts

2005-10-26 Thread Greg Black
On 2005-10-26, Mark Andrews wrote:
   Leading zeros are ambigious.  Some platforms treat them as octal
   others treat them as decimal.

There is nothing ambiguous about the example provided.  (Perhaps
it wasn't a good example, but it's always a bug if '04' is not
correctly decoded, regardless of the numeric base in use.)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Resolver doesn't like 1.2.3.04 in /etc/hosts

2005-10-26 Thread Matt Emmerton
 On 2005-10-26, Mark Andrews wrote:
  Leading zeros are ambigious.  Some platforms treat them as octal
  others treat them as decimal.
 
 There is nothing ambiguous about the example provided.  (Perhaps
 it wasn't a good example, but it's always a bug if '04' is not
 correctly decoded, regardless of the numeric base in use.)

Not to belittle the point, but '04' is invalid for base-2/3/4.

--
Matt Emmerton
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Resolver doesn't like 1.2.3.04 in /etc/hosts

2005-10-26 Thread Greg Black
On 2005-10-26, Matt Emmerton wrote:
  On 2005-10-26, Mark Andrews wrote:
   Leading zeros are ambigious.  Some platforms treat them as octal
   others treat them as decimal.
  
  There is nothing ambiguous about the example provided.  (Perhaps
  it wasn't a good example, but it's always a bug if '04' is not
  correctly decoded, regardless of the numeric base in use.)
 
 Not to belittle the point, but '04' is invalid for base-2/3/4.

The bases discussed here were 8 and 10; my comment applied to
them.  As for base 3, I don't care what you write using it, I
won't be bothering about it.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Resolver doesn't like 1.2.3.04 in /etc/hosts

2005-10-26 Thread Mark Andrews

 On 2005-10-26, Mark Andrews wrote:
  Leading zeros are ambigious.  Some platforms treat them as octal
  others treat them as decimal.
 
 There is nothing ambiguous about the example provided.  (Perhaps
 it wasn't a good example, but it's always a bug if '04' is not
 correctly decoded, regardless of the numeric base in use.)

You want a ambigious example?

192.168.222.012

Seen this sort of thing in real life when the admin wanted
to make the file look pretty and they wanted 12 for the last
octet not 10.

Seen boxes that used %03u.%03u.%03u.%03u to print out the
octets.

It's much easier to just reject octal and hexadecimal than
to work out when and when not it is ambigious.  It is also
better to demand all 4 octets.  It also generates less
support complaints.

Mark

 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]