If I use a printf/sprintf format for float like "%3.0f" it should print the float without the fractional part.
Ex.: n = 2.718 -> output should be: 2
If I use the format "%3.1f", the output should be 2.7
The problem I found in MQX 4.02 is, when I use the first example, "%3.0f", the output is 2.7, instead of 2
Exactly the same behaviour if I use "%3.1f".
It seems to me to be a bug but at "io_dopr.c" there is a code that force this situation; I commented the code (as seen below) and now it is working fine.
Could someone explain me this?
I do not like to work with a modified MQX.
Is there anyother solution for this issue?
thank you all...
case 'f':
case 'F':
if (! prec_set) {
prec = 6;
} /* Endif */
//?? /*
if (prec == 0) {
prec = 1;
}
*/
Solved! Go to Solution.
Hi,
this is a bug. I'm creating ticket for this. Also please note, that just commenting out given lines isn't sufficient. According to GCC output for '2.718' and format "%3.0f" should be 3, not 2. This means rouding works here.
Rene
Hi,
this is a bug. I'm creating ticket for this. Also please note, that just commenting out given lines isn't sufficient. According to GCC output for '2.718' and format "%3.0f" should be 3, not 2. This means rouding works here.
Rene
Hi,
I've just found another MQX double float format bug:
If the double to be printed is different from 0, it works correctly:
printf("%10.0lf\n", 1.); -----> give an "1" at stdout
If the double to be printed is 0, it adds an undesired '.':
printf("%10.0lf\n", 0.); -----> give an "0." at stdout
I'm using MQX 4.1.
Hi,
bugfix for the first will be present in MQX 4.1.1, expected release date is end of June. I confirm the second one is a bug, I've reported it but cannot confirm resolution date or version.
Hi Rene,
I have just updated my MQX to 4.1.1.
Unfortunately the printf with argument "%3.0f" still doesn't work. It insists in put an undesired 'dot zero' at the end of the printed number:
printf("%10.0lf\n", 3.14); gives: '3.1' (but should be just '3') |
printf("%10.1lf\n", 3.14);
gives: '3.1' (that's right)
Hi Rene,
18 months later this discussion, another float format problem was found.
I'm still using MQX 4.1.1, with the corrections discussed in this post.
I'm using the float format "%0.02f" to obtain outputs of type "x.yz".
If the number is, for example, 1.234, I get "1.23" ---> that's right.
But if the number is less than one, for example, 0.123, the output string is "012" (without dot) and not "0.12".
Another workaround or correction I could apply?
thank you,
sandro
bfac
Hi Sandro,
I suggest you to create a new thread and add this link as a reference due this case was closed.
In Linux, you can use 'patch' utility. In Windows you can use git scm's command 'git patch'. But you don't need to use the patch if you don't want to, because the changes needed are small. First, your workaround is right but you need to add this:
In file 'io_fp.c', row 799 there is the expression:
*bp++ = '.';
You need to change it to:
if (decpt < 0)
*bp++ = '.';
And you are done :smileycool:
Ok, it was exactly what I did; opened the patch as a text and made manually the fixes.
It worked fine! The second fix you suggested in 'io_fp.c' solved the "0." problem.
Thank you very much Rene.
best regards,
sandro
Hi Rene,
Yes, I did a workaround at "io_dopr.c"; there is a code that force this situation; I commented the code (as seen below) and it seems to work fine.
case 'f':
case 'F':
if (! prec_set) {
prec = 6;
} /* Endif */
//------My Workaround------------------------
//?? /*
if (prec == 0) {
prec = 1;
}
*/
//-------------------------------------------
But a little problem still remains:
If the double to be printed is different from 0, it works correctly:
printf("%10.0lf\n", (float)1); -----> give an "1" at stdout
If the double to be printed is 0, it adds an undesired '.':
printf("%10.0lf\n", (float)0); -----> give an "0." at stdout
//-------------------------------------------
I'll try out your patch.
thank you,
regards
Hi, I'll check it asap.
Hi sandrobastos,
Please create a new discussion for your last question/issue.
Hi Karina,
This last bug is, in fact, regarding to the old one posted above - I believe that in a further version they will be fixed together.
Thank you.
rendy can you comment about previous update from Sandro please?
Dear Rene,
The rounding is already done correctly. I just checked with the 2.718 example and it works.
I had an '3' as output, i.e. it was rounded by the code.
So, just commenting that code is enough.
Thank you.
Hi Rene,
You are absolutely right! The number must be rounded.
Will this bug be fixed in MQX 4.1 ?
thank you - regards...
Unfortunately fix of this bug cannot go to 4.1.0 because it's already in code-freeze phase. Sorry.