Fixed 4UTILS bug in @iptohex

May 29, 2008
532
3
Groton, CT
#1
Vince,

When translating dotted (decimal) IP addresses to hex, if one or more of the components has a leading zero specified, that number is translated as octal.

> ECHO %@IPTOHEX[10.11.12.13]
0A0B0C0D

> ECHO %@IPTOHEX[010.011.012.013]
08090A0B

What I am trying to do is canonicalize an IP address which may have leading zeroes with
%@HEXTOIP[%@IPTOHEX[%foo]]

When foo is 010.011.012.013, the result is 8.9.10.11 .

Any chance you can fix this?
 
#3
On second thought, perhaps it's supposed to be that way. I'm just using the function inet_addr() which is documented to behave that way. And that behavior seems to carry over in at least two MS utilities.
Code:
l:\projects\4utils\release> ping 128.230.013.036
 
Pinging 128.230.11.30 with 32 bytes of data:
Control-C
^C
l:\projects\4utils\release> nslookup 128.230.013.036
Server:  dns-cac-lb-01.rr.com
Address:  209.18.47.61
 
*** dns-cac-lb-01.rr.com can't find 128.230.013.036: Non-existent domain
 
l:\projects\4utils\release> nslookup 128.230.13.36
Server:  dns-cac-lb-01.rr.com
Address:  209.18.47.61
 
Name:    lucky.syr.edu
Address:  128.230.13.36
 
May 29, 2008
532
3
Groton, CT
#4
I see your point, but I think that just means that inet_addr() is broken.

I hope you'll add a note to your documentation for @IPTOHEX that it works that way.

Thanks for the quick attention.
 
#8
I suspect the origin of the issue is the old C language behavior of integers starting with 0 being octal...
My guess would be old (possibly persistent today) ways that network programmers used to think. The network APIs are ancient, probably going (way) back to "Berkely sockets" and a time when octal representation was common