Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Another way of specifying an IP address in Cocoa apps' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Another way of specifying an IP address in Cocoa apps
Authored by: notmatt on May 28, '03 12:39:32PM

IP address are just 32-bits of information, the "segments" are just for readability, and don't exist anywhere except for when they're displayed, so in that sense, using a 32-bit number for them makes sense.

However, I don't think this is a Cocoa feature; I remember this working just fine on windows IE browsers, and it was noted as a security risk, since you could get URLs like the following:

http://www.cnn.com@3475821262

which looked relatively innocuous to the unseasoned user, and could be used to spoof someone into downloading something nasty. I'm not entirely certain, but I actually think that it's one of the standard representations of an address, but I'd rather not wade through RFCs to confirm my suspicion. Anyone know for sure?



[ Reply to This | # ]
Another way of specifying an IP address in Cocoa apps
Authored by: greed on May 29, '03 11:17:39AM

If you're looking up RFCs, you'll want to go waaaaay back to the "class-based" addressing schemes. Remember class A, B and C addresses?

Anyway, parsing an IP number this way is an artifact of the inet_aton (or the older inet_addr) routines. Any program which converts an IP address string to an actual IP address value will get that conversion trick. And the "0x" bit comes from the C strtol family of routines. (Try a leading "0" for octal.)

Some of us recall the old MacTCP control panel where you had to enter the "network" and "host" part separately, and you couldn't use dots within the name, so you'd have to do (for my network) "network 10", get out Calculator and work out 12 * 65536 + 0 * 256 + 37 for the host part. And then realize that you were actually using a subnet, so you'd done that all wrong and it should be "10 * 65536 + 12 * 256 + 0" for the network....

So what's really happening in inet_ntoa? (This is backed up with tests on my Linux host.)

No dots --> No network address, 32 bit host address
1 dot --> 8-bit network, 24 bit host (class A)
2 dots --> 16-bit network, 16-bit host (class B)
3 dots --> 24-bit network, 8-bit host (class C)

So we usually use class C formatted IPs, even though we no longer use class-based routing. They're just easier to work with.

Try accessing Apple's site at 0x11.034114040. That'll tell you how versatile your parser is. It seems many browsers are now blocking "imaginative" IP encodings. which is too bad, as hex coding IP numbers is useful for network testing.

The practical upshot for programmers is that you CANNOT process IP addresses in text, you must convert to binary first. (You can convert back to a canonical text form if you like, I guess.)



[ Reply to This | # ]