Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Fixed 4UTILS bug in @iptohex

May
572
4
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?
 
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
 
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.
 
On the other hand, I never intended it to work like that and I doubt there are many who rely on that behavior. I'll post a new version in a few minutes.
 
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
 
Back
Top