E.g. "32-48" -> 32.0

Caused by change 2 here.

This string parsing behavior is maybe acceptable for strings being passed into a math function, but it's completely unacceptable here. Also, it's useful for debugging to be able to get hexadecimal UNIDs, rather than converting them to int32.

I'd suggest xmlGetAttrib should only convert to a number if all the characters in the string are numerals, except for up to one E/e (which isn't first or last), up to one decimal point (before the E if present and not first), and up to two - signs (only at the start and directly after an E).

Math and equality functions should probably convert valid hexadecimals, but otherwise they could use the same standard.

nms 20 Sep 2017:

Workaround: replace xmlGetAttrib calls with this function:

(setq NMS_xmlGetAttrib (lambda (xml attrib)
	(block (string pos)
		(setq string (convertTo 'string xml))
		(setq string (subset string 0 (strFind string ">")))
		(if (setq pos (strFind string (cat " " attrib '=)))
			(block (quoteType)
				(setq string (subset string pos))
				(setq quoteType (subset string (add (count attrib) 2) 1))
				(setq string (subset string (add (count attrib) 3)))
				(subset string 0 (strFind string quoteType))
george moromisato 17 Feb 2018:

I've fixed xmlGetAttrib in 1.8 Beta 1 so that it does not convert strings to numbers unless the whole string is a number. [This was the original intent, but there was a bug.]