Str-to-IP strange results for some IP numbers

[volker.dreiling@dlr.de]

For some reason I used the String form "192.168.0.030" and found that the result in numerical representation (using the Str-IP Function in TCP Protocol Palette) is different if you compare it to the form "192.168.0.30". This seems to appear at least for all IP numbers from ".10" to ".99" in the last position.

The re-conversion using the corresponding IP-to-Str function works correct except one very strange case where the conversion of "192.168.0.099" results in back-conversion as "255.255.255.255".

The errors disappear for IP values > ".100" in the last position

[playerm1]

I don't have an answer but it looks like there is another case that is strange.  The 192.168.0.020 re-conversion yields an incorrect result of 192.168.0.16.

[deceased]

---

volker.dreiling@dlr.de wrote:

The re-conversion using the corresponding IP-to-Str function works correct except one very strange case where the conversion of "192.168.0.099" results in back-conversion as "255.255.255.255".

---

In the case of .020, the re-conversion changed it to .16 in your example.

[deceased]

Hmmm Something strange here with Octal <-> Decimal.

.020 becomes .16

.070 becomes .56

70OCT is 56DEC

20OCT is 16DEC,

0xDEAD

[volker.dreiling@dlr.de]

No, the re-conversion takes the wrong conversion number as input. This results in the error.

[volker.dreiling@dlr.de]

could be the answer - numers with leading 0 are interpreted as octal. But 099 does not exist in octal!

[deceased · Accepted solution]

---

volker.dreiling@dlr.de wrote:

could be the answer - numers with leading 0 are interpreted as octal. But 099 does not exist in octal!

---

The String To IP function accepts standard decimal, octal, or a combination of both number systems. If you enter a leading zero into a string, the String To IP function interprets the string as an octal number.

^^ from context help. LOL (Should have read it sooner).

Mystery solved.

0xDEAD

[volker.dreiling@dlr.de]

Yes, it's a RTFM problem. But the 099 result is interesting nevertheless.

Thanks for helping.

[deceased]

No worries. Wheres the fun in that manual anyway....

0xDEAD

[altenbach]

On a side note, make sure to wire a TRUE to the "dot notation" input of "IP to string", else it will try to do a DNS lookup for each entry, which (in my case) takes a very, very long time.

Of course "string-to-IP" works equally well for real names (e.g. "www.ucla.edu"), so there needs to be a mechanism to detect if it is a well formed decimal dot notation. Leading zeroes is not well formed. I also don't really see the usefulness to ever use octal. Not sure why that option even still exists. Wikipedia has a note: 

"It also allowed the numbers to be written in hexadecimal and octal, by prefixing them with 0x and 0, respectively. These features continue to be supported by software until today, even though they are seen as non-standard. But this also means addresses where an IP address component is written with a leading zero digit may be interpreted differently by different programs: some will ignore the leading zero, some will interpret the number as octal."

IMHO, LabVIEW should drop the octal interpretation (or also support the hexadecimal interpretation). Seems half-baked. 😉

If you know that the IP string is in decimal dot notation, you can of course write your own to silently drop leading zeroes from each octet.