подозреваю, что недопонимаю какие-то банальные вещи....Вопрос касается преобразования IP адреса, при наличии нуля в начале числа (в десятичном виде). Я опишу ситуацию, поправьте пожалуйста в чем ошибаюсь.
OS - Solaris:
telnet 10.140.33.55
Trying 10.140.33.55...
Все нормально, все как всегда
Догадались пользователи дописать 0:
>telnet 10.140.33.055
Trying 10.140.33.45...
> telnet 10.140.033.055
Trying 10.140.27.45...
Аналогично в Debian Lenny.
В вин. ХР тоже адрес меняется:
ping 10.140.033.055
Обмен пакетами с 10.140.27.45 по 32 байт
Я правильно понимаю, что при наличии нуля число считается в восьмеричной системе, т.е 033 - это 33 в восьмеричной = 27 в десятичной, аналогично 055 - это 55 в восьмеричной = 45 в десятичной?
Не до конца понятно в связи с чем происходит такая трансформация IP адреса. Это спецификация IP протокола? (бегло просмотрел RFC 791, не нашел...).
Может это быть связано именно с программной реализацией клиентских приложений (telnet, ping...)?
Другой пример - берем адрес 10.140.33.95, добавляем 0:
Solaris:
telnet 10.140.033.095
Trying 10.140.27.77...
т.е. 095 преобразуется в 77, несмотря на то, что "9" в восьмеричной системе нет.
В Debian Lenny
telnet 10.140.033.095
telnet: could not resolve 10.140.033.095/telnet: Temporary failure in name resolution
ping 10.140.033.095
ping: unknown host 10.140.033.095
При этом в винде:
>ping 10.140.033.095
Обмен пакетами с 10.140.033.095 [10.140.33.95] по 32 байт
при наличии "9", которой нет в 8-ной системе не преобразуются остальные числа с начальным нулем (033 - остается 33).
(в свойствах сетевых подключений в офтопике тоже нормально обрабатываются IP с нулями и без).
Т.е. получается все-таки программная реализация? где-то эти нули программно отсекаются, а где-то IP адрес, указанный как аргумент передается "как есть"?
Также по-диагонали просмотрел исходники inetutils-1.8.tar.gz отсюда, но С не знаю, не нашел обработку аргумента (что происходит с IP адресом, передаваемым в качестве параметра).
