3

I'm programming on a STM32F437. I'm using SafeRTOS. The compiler is GCC.

In one task I'm using snprintf() to prepare a string with values.

The problem is that the snprintf() fails to handle floating point numbers. It just ends the resulting string (with '\0') when it reaches any %f or %g in the formatting string.

But, and this is strange. The snprintf() in the task works with no problem if I add a dummy call to snprintf() in main() before starting the RTOS.

The dummy call: 

char dummy[20];
snprintf(dummy, sizeof(dummy), "%g", 3.14159);

I found a similar solution here

But no answer why it works.

Any ideas what is going on?

Iharob Al Asimi
  • 52,653
  • 6
  • 59
  • 97
Eerik Sweden
  • 375
  • 6
  • 17
  • `snprintf` won't necessarily add the `0` terminator to the output string; can you try with regular `sprintf` and an explicit width and precision on your conversion specifier? – John Bode Apr 24 '15 at 12:13
  • 2
    @JohnBode: "*`snprintf` won't necessarily add the 0 terminator to the output string ...*" this would be the case when, please? – alk Apr 24 '15 at 12:21
  • @JohnBode, man page of `snprintf` says this `The functions snprintf() and vsnprintf() write at most size bytes (including the terminating null byte ('\0')) to str.` – niyasc Apr 24 '15 at 12:29
  • What is the stack size of the task that works versus the task that does not? Or, just check for a stack overflow. – kkrambo Apr 24 '15 at 12:48
  • 1
    @alk: that would be the case when I haven't had my RDA of caffeine. I must have been thinking of `strncpy`. Disregard. – John Bode Apr 24 '15 at 13:06
  • The stack size was set to 512 byte first, then I changed it to 8192 byte. It did not help. – Eerik Sweden Apr 24 '15 at 13:07
  • Insure there is _other_ floating point code: `float a = sqrt(5.0);sprintf(dummy, sizeof(dummy), "%g", a);` . Some compilers use the lack of floating point code to not employ the `printf()` support of FP. – chux - Reinstate Monica Apr 24 '15 at 14:01

2 Answers2

0

The printf library in some small implementations does not include floating point support. Perhaps the dummy call is somehow causing a more complete (and larger) library to be used?

John Hascall
  • 9,176
  • 6
  • 48
  • 72
0

The dummy call may be optimized away by compiler. As you are printing only constant. Try to look in disassembly or try to compile it with -O0 flag set.

Float support in general tends to be large, especially on platforms without hardware FPU available where all computing operation have to be done by calls to the library. So many standard libraries just omit it unless you explicitly specify that you want it enabled.

Vladislav
  • 26
  • 2