--- Gerald Combs wrote:
Jack wrote:
...
I would say that this is a bug in ping, that it
would
allow x.y to be evaluated as a complete ip
address.
But what is going on is that ping is calculating
the
address based on the first and last dot numbers
and
fills in the blanks with zeros. ...
The behavior is on purpose, and happens when ping passes the address to the inet_aton() function. inet_aton() tries its best to convert
...
The man page has more information (under "Internet Addresses"):
http://www.freebsd.org/cgi/man.cgi?query=inet_aton&sektion=3
Well just because it is done on purpose, and I suspected it was. Does not make it not a bug. I still consider it a bug. Here's my reasoning, if a program does an interpretation of the user input that the user might not have intended then ... it might be a bug. If a program behaves in an irrational way to input then ... it might be a bug. If a program fills in missing information then ... it might be a bug.
It's certainly a nice little l33t trick for those in the know to use for short-cutting, etc. But, it's still is translating what might have been an accidental <CR>. I might want to ping 12.1.0.5, but if my hand slips and I hit return after 12.1 or 12.1.0 then I wind up pinging the wrong address (12.0.0.1 or 12.1.0.0). But even bugs have uses, whether they are intentional or not. ;')
Thanks for the trivia, Gerald.
Brian D.
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Wed, May 4, 2005 8:57 am, Jack said:
I might want to ping 12.1.0.5, but if my hand slips and I hit return after 12.1 or 12.1.0 then I wind up pinging the wrong address (12.0.0.1 or 12.1.0.0).
Oh horrors! You could end up pinging the wrong address if your hand slipped! It could be almost as bad as if you slipped and entered the wrong address!
I suggest that you immediately recode all of the effected programs, and issue an official RFC regarding this terrible danger.
The intarweb must be protected!