05-19-2008 10:54 AM
05-19-2008 12:22 PM
05-19-2008 12:36 PM - edited 05-19-2008 12:37 PM
05-19-2008 02:24 PM - edited 05-19-2008 02:30 PM
05-19-2008 03:55 PM
For what it's worth a 7.1 compiled source run on the new system with the 8.1 Runtime returned 80000000h. So far it looks like there could have been a "fix" to the cvi runtime. I remember reading your thread on the serial issue, tough situation. I am probably in a better situation than you were in. It could be argued that in this case the runtime is backward compatible, and that the representation of -0.0 without the msb set was in fact a bug and that it has been fixed. But in this case whetever has changed has exposed an issue in our system. I can accept that as perfect compatibility is too much to ask for.
I do not control the input data stream. Technically -0.0 is probably invalid but it is out of my control. Gotta love a legacy system. It is easy to deal with from a code standpoint as I can trap for the value 80000000h and convert it to 0, no issue there. But my problem is similar to what you experienced in that a change to NI hardware or software in fielded systems can cause a runtime upgrade which will then expose this issue in our CVI based application. The validation process for this software on a hardware system is not trivial. If this is in fact runtime library related, I do have a paperwork based path to force an application software update if the runtime gets updated on the system. But to do this I need to specifically state which runtime versions will trigger the change. I am going to have to prove that I understand the nature of the issue, when it will occur and how it will be corrected.
Some of the usage of this system is very deeply buried in burocracy, I am sure you know how that goes.
05-20-2008 03:24 AM
05-20-2008 12:07 PM
05-22-2008 02:28 PM
Hello mvr,
I can confirm that the implementation of atof changed between 8.0.1 and 8.1. The reason for the change was because of a bug in which the conversion was incorrectly being affected by the number of digits of precision in the input string (for example, "8.0" might have converted differently than "8.0000").
To fix this bug, we replaced our own implementation of strtod with that of a 3rd party implementation (for specifics on the implementation we're now using, look in the CVI online help, in the Important Information>>Copyright topic). That change must have been what introduced this sign bit change that you ran into. We didn't list this in the release documentation for 8.1 because our testing hadn't uncovered any behavior change as a result of the change. Obviously, we missed this one. I'm really sorry for the trouble this has caused.
Luis
05-22-2008 03:25 PM