We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi, the following code for STM32F4 (Cortex-M4):
float fZero= 0.; float fInfinity; short sTestPlus, sTestNeg; int main( void){ fInfinity= 1.f/fZero; sTestPlus= fInfinity; fInfinity= -1.f/fZero; sTestNeg= fInfinity; while(1); }
should result in the values sTestPlus= 0x7FFF and sTestNeg= 0x8000. Instead it produces 0xFFFF and 0x0000.
The reason is, that the compiler uses the signed 32bit convert (leading to the correct result 0x7FFFFFFF and 0x80000000), and then just cuts out the lower short, which is really poor.
As I understand, it is no problem with Cortex M4 to do float to signed16 using the VCVT command in a more sophisticated way (specifying 16bit).
Is there a way to get this done?
"(further of course I would suggest to fix the problem, that "i=f" produces a wrong conversion for int8/int16/... - it is a bit disturbing/ "a bad surprise" if this works without problems for int32, but then you run into problems as soon as you use int8 or int16)."
And how many thousands - or tens of thousands - or even hundreds of thousands (dare I say million?) of programmers have stumbled on this:
uint8_t ii; for (ii = 0; ii < 256; ii++) { ... }
Yes, people will always suffer "a bad surprise" when they make use of char or short variables together with numbers larger that what fits in that numeric range, and they make specific expectations about the outcome (or just totally ignores that there can even be an issue).
When mixing variables with different numeric range, it is you, the developer, who have to take the consequences of assuming what the outcome will be when the smaller variable is too small in relation to the numeric value of the larger variable.
There are quite a number of paragraphs in the language standard discussing mixing of variable types of different size, mixing of signed/unsigned etc. Have you read the language standard? Did you understand it? Did you realize that the language standard forms a contract? Do you think end users of a programming language are in the position to renegotiate a contract? Because in the end, your request is that Keil should add a secondary contract with additional promises outside of what is covered by the language standard. And you formulate it as if it is a direct error of Keil to not have this additional contract available, and already signed.