Für mich eigentlich ein "Fehler" in inet_aton()

[Dubu]

Meiner Meinung nach liegt der Fehler eigentlich _nicht_ in den Libs, sondern in dem Unsinn, in IPv4-Adressen Hex- oder Oktaldarstellung zuzulassen. Diesen Unsinn findet man in den leider viel genutzten Systemfunktionen inet_addr() bzw. inet_aton(), und ja, es ist dort so dokumentiert. Im neueren inet_pton() (das auch mit IPv6 klar kommt) wird dagegen explizit vorgeschrieben, dass die Oktetts in IPv4-Adressen dezimal sein müssen, führende Nullen hin oder her.

Wenn man in die alten RFCs zu Internetadressen schaut, wird man auch feststellen, dass die ursprüngliche Schreibweise mit führenden Nullen war. In RFC 790 findet man z.B. eine Liste der ersten Class-A-Netze, mit Einträgen wie:

019.rrr.rrr.rrr TYMNET TYMNET [VGC]

(offensichtlich nicht oktal)

Auch sind mir früher verschiedentlich Systeme untergekommen, die ihre IPv4-Adressen grundsätzlich mit führenden Nullen darstellen, z.B. "192.168.002.042". Das sollte man dann nur nicht so in inet_aton() füttern.

[schnedan]

klingt eigentlich logisch, vor allem, weil ich bei der Darstellung der IP ggf. eine fixe Breite haben möchte - und schon machen führende Nummern Sinn