socket.inet_aton - bug?

[Donn Cave]

Quoth "Steve Holden" <sholden at holdenweb.com>:
| "Uwe Mayer" <merkosh at hadiko.de> wrote ...
|> socket.inet_ntoa() accepts the string '\xff\xff\xff\xff' which is
|> excactly the same i'd expect socket.inet_aton('255.255.255.255') to
|> produce if it accepted the string '255.255.255.255' as an IP adress.
|> socket.inet_aton() dies with socket.error "illegal IP adress".
|>
|> i know this is no valid ip adress, but it is a valid netmask. the
|> purpose of converting the netmask to a binary format was that i wanted
|> to isolate the subnet of an ip adress.
|> i wanted to use test_ip & netmask == ip_range to allow subnets to access
|> a tcp server.
|> is there another way of controlling this or why does socket.inet_aton()
|> behave like that?
|
| I can't really tell you why socket does that, but it seems to be a feature
| of the underlying C socket library, which is where inet_aton() is defined.

Yes (you mean "C socket module", I suppose - at first I thought you were
pointing to the C library inet_aton.)  The good news is that it's only
this one value, which happens to be identical to INADDR_NONE, and that
this value is reliably -1.  So at worst, there's a work-around.

| The address 255.255.255.255 is, in fact, a valid destination for a
| restricted broadcast (one which should be sent out only to hosts on the
| local LAN).

	Donn Cave, donn at u.washington.edu