printf float format like "%3.0f" does not work

cancel
Showing results for 
Search instead for 
Did you mean: 

printf float format like "%3.0f" does not work

Jump to solution
3,636 Views
sandrobastos
Contributor IV

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;

            }

            */

           

BrunoCastelucci

rendy

karinavalencia          

1 Solution
639 Views
rendy
NXP Employee
NXP Employee

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

View solution in original post

0 Kudos
18 Replies
640 Views
rendy
NXP Employee
NXP Employee

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

View solution in original post

0 Kudos
639 Views
sandrobastos
Contributor IV

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.

bfac

rendy

DavidSeymour

karinavalencia

0 Kudos
639 Views
rendy
NXP Employee
NXP Employee

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.

0 Kudos
639 Views
sandrobastos
Contributor IV

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)

rendy

0 Kudos
639 Views
rendy
NXP Employee
NXP Employee

Hi, I confirm your observations. I have created a patch for this and I will send it to MQX team and push them to integrate it to the next release.

639 Views
sandrobastos
Contributor IV

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

rendy

karinavalencia

bfac

0 Kudos
639 Views
karina_valencia
NXP Apps Support
NXP Apps Support

Hi Sandro,

I suggest you to create a new thread and add this link as a reference due this case was closed.

639 Views
sandrobastos
Contributor IV

Rene,

I'm sorry but, how do I apply the '.pathc' file?

rendy

0 Kudos
639 Views
rendy
NXP Employee
NXP Employee

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:

639 Views
sandrobastos
Contributor IV

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

0 Kudos
639 Views
sandrobastos
Contributor IV

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

0 Kudos
639 Views
rendy
NXP Employee
NXP Employee

Hi, I'll check it asap.

0 Kudos
639 Views
karina_valencia
NXP Apps Support
NXP Apps Support

Hi sandrobastos,

Please create a new discussion for  your last  question/issue.

0 Kudos
639 Views
sandrobastos
Contributor IV

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.

0 Kudos
639 Views
karina_valencia
NXP Apps Support
NXP Apps Support

rendy can you comment about  previous update from  Sandro please?

0 Kudos
639 Views
sandrobastos
Contributor IV

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.

0 Kudos
639 Views
sandrobastos
Contributor IV

Hi Rene,

You are absolutely right! The number must be rounded.

Will this bug be fixed in MQX 4.1 ?

thank you - regards...

0 Kudos
639 Views
rendy
NXP Employee
NXP Employee

Unfortunately fix of this bug cannot go to 4.1.0 because it's already in code-freeze phase. Sorry.

0 Kudos