Perhaps many of your troubles are caused by using a newlib that has not been properly configured for your particular setup.
For sure, but ST didn't supply the sources or any build data. What you get when you install Cube is a separate directory c:\st\all-kinds-of-stuff and in there are about 20 different libc.a versions which they precompiled. I spent many hours working out which one of these is selected for my project. Much of it was by elimination (some were for arm32 chips with DSP instructions, etc) and eventually I found the one file which was "standard C, no nano". You can tell if you have nano because int64 etc is not supported, also a sscanf can't read into a uint64_t (which I am doing). Then, as I posted on another thread, I made a permanent local copy of it, ran objcopy to weaken the entire lib, then I replaced the printf family with another one.
So far I see no evidence that malloc is getting called by the scanf family, but perhaps somebody with super C expertise can suggest which % formats might trigger that.
The modern thread-safe design is to use stack storage. If one uses statics one must have mutex calls
within the code.
These were originally empty stubs. If one uses the heap one must also have mutex calls to protect the heap, but these could be outside (around malloc and free). I have since secured the heap functions with mutexes, so the sscanf should be basically thread-safe even if it does use the heap, but (if calling sscanf from more than 1 RTOS task) one still gets fragmentation which will eventually crash the product.
Those two check boxes will only have effect if you select the "Reduced" library - i.e. newlib-nano, as per the attached screenshot.
Yes; I worked that out but it took more hours. I realised what was going on when I selected the nano options but my uint64_t sscanf still worked... Stupid interface design.
Anyway I wrote it all up so others don't have to do it all again.