AnsweredAssumed Answered

sprintf bug when using newlib nano with "-u _printf_float" linker option

Question asked by Dan Teodorescu on Aug 22, 2018
Latest reply on Sep 7, 2018 by Dan Teodorescu

Hello,

 

I am using S32 Design Studio 2017.R1 for an MPC5777C project. Because of the embedded real-time nature of our project, we are using S32DS newlib nano as the standard "C" library. By default this library does not provide support for sprintf floating point format specifiers, unless "-u _printf_float" is added as a linker command line option.

 

I added the linker command line option mentioned above, but sprintf() does not work as expected. In my test code the contents of buffer are "nan xyz", instead of "1.0 xyz" right after the call to sprintf() returns.

 

int main()
{
    char buffer [256];
    sprintf(buffer, "%f xyz", 1.0f);
    counterclass myccounter;

    xcptn_xmpl (); /* Configure and Enable Interrupts */

    /* Loop forever */
    for(;;) {
        myccounter.increment();
    }
}

 

I have attached my test project, including the code above, newlib.c (which resolves the missing syscalls that newlib expects), and the compiler/linker settings.

 

I saw similar behavior in our actual application. In that project I narrowed down the issue to variable _fpvalue getting a value of 0xFFFFFFFFFFFFFFFF in _printf_float (nano-vfprintf_float.c).

 

int
_printf_float (struct _reent *data,
        struct _prt_data_t *pdata,
        FILE * fp,
        int (*pfunc) (struct _reent *, FILE *, _CONST char *,
        size_t len), va_list * ap)
{

    /* ... */

    if (pdata->flags & LONGDBL)
    {
        _fpvalue = (double) GET_ARG (N, *ap, _LONG_DOUBLE);
    }
    else
    {
        _fpvalue = GET_ARG (N, *ap, double);

        /* _fpvalue is now 0xFFFFFFFFFFFFFFFF even though argument to sprintf was 1.0f. */
    }

    /* ... */

}

 

Has anyone seen this issue and is there a fix for it?

 

Thank you

Outcomes