Hello,
I have a question about the stdlib printf functions. If I use not "valid" floating point numbers, which is the case when memory is not initialized, then my snprintf function "hangs" (is looping internally). I have increased the heap to 500 and stack to 200. I am using CCS 5.1.1.00028 and MSP430. I tried compiler toos 4.0.0, 4.0.2, and 4.1.0 but nothing worked.
Do I have to provide some error callback functions? Where can I find detailed documentation about how to implement this functions?
Is this a bug?
If this is not a bug, how can I check if it is a valid floating point value?
Reproducible code:
void main(void) { char str[40]; volatile float test; ((char*)&test)[0] = 0x6d; ((char*)&test)[1] = 0x6d; ((char*)&test)[2] = 0; ((char*)&test)[3] = 0; while(1) { snprintf(str, 30, "%f", test); _NOP(); } }
Thanks,
Joachim
For IEEE-754 32-bit format, 0x00006d6d is 3.92546e-41f, which is a denormal (subnormal) number. The TI compiler doesn't support denormal numbers, and that in part manifests as library functions which can't handle them as input, and which do bad things like loop forever or return bogus results. You have to take care not to pass such numbers to any library function. There isn't a library function which tests whether a given bit pattern represents an IEEE-754 value that the library can handle.
In addition, it's technically undefined behavior to pass an uninitialized value to a library function, so doing so is not portable.
Hello Archaeologist,
ok - so does that mean if I want to create a robust software, I have to validate every floating point value that is loaded from external memory or internal flash? In my case I am storing floating point values in flash memory. Anyway, how do I check this correctly?
Suppose the memory from where the application is "loading" the float values gets corrupted (power loss or something else) and these values are not validated then the application crashes. There helps no watchdog or other mechanism because every thime the application crashes... Strange behavior in my opinion. Other implementations of printf I have seen prints a "NAN" or simply "0" but such behavior I havent seen until now.
Does TI somewhere inform customers about this behavior?
Thanks for helping,
Unfortunately, there is no solution at the moment. The TI library doesn't make any sort of allowance for potentially corrupted floating-point input. The issue runs deeper than just printf; the underlying floating-point emulation functions need to be overhauled to support Inf, NaN, and denormals correctly. Certainly, we would prefer that printf at least not crash in the face of corrupted input, but fixing the floating-point emulation on a device that doesn't have floating-point hardware just doesn't get prioritized over the other work that needs to be done. I've submitted SDSCM00043971 to track this issue.
I can think of only one workaround: don't print float values that aren't known to be correct. Values can be assumed to be correct if they are generated by the program, or you could write a function to pick the bits apart and test for special values like NaN, Inf, -0, and denormal numbers. I know this is unpleasant, but that's the way it is today.
No, there is no documentation on the flaws of floating-point in TI compilers that I'm aware of.
first thank you for your help. I am developing now embedded software for now about 12 years, worked with a lot of compilers until now. For me this is clearly a bug and maybe a big security risk for some applications, too. I will try to find an secure workaround.
> Certainly, we would prefer that printf at least not crash in the face of corrupted input, but fixing the floating-point emulation on a device that doesn't have floating-point hardware just doesn't get prioritized over the other work that needs to be done.
Hm - I thought that CCS is TI´s pfefered compiler for MSP430? No MSP430 device has an fpu as far as I know. Does TI really think that no one uses floating point operations in your devices without fpu? I hope not ;)
Sorry Archaeologist for this discussion - I just want to make clear that TI has to solve this issue and not only years later. Perhaps TI sees this with other eyes but I would not buy security devices if would know the controller has such "feature" ;)
TI should mention this somewhere that there exists this known problem.
Again thanks for helping,
ArchaeologistNo, there is no documentation on the flaws of floating-point in TI compilers that I'm aware of.
Results of single precision attached.
Hello Chester,
very interesting, thanks.
Regards,
8883.double_results.txt
8156.single_results.txt
Chester Gillon Note the overall rating for this test program of "Unacceptable".
It turns out that there is a bug in esparanoia.c when NOSETJMP was defined which overwrote some variables. With NOSETJMP removed from the project, the overall rating for single and double precision was "Good". The updated results are attached.
I will contact the auther of Embedded System Paranoia.