Heap_5 with stdlib

Dear,
I implemented heap_5 and it works perfectly, but for some stdlib functions that I use as strtok, they use malloc_r being out of the context of heap_5 and generating error.
My question is how Freertos addresses this situation.
The development environment used is KDS 3.2 with a K64F processor.

Aren’t strtok() and malloc_r still using the original malloc()? Or did you redefine malloc() to use heap_5?

I have made #define malloc (size) pvPortMalloc (size), but this applies to the malloc that I write, I don’t know how to make stdlib also comply with this directive.

Unless you recompile the library with your define in it, it won’t change what the library calls. If your library is newlib, and the vendor compiled it right, then there is a way to make malloc thread safe by defining functions _malloc_lock and _malloc_unlock to protect the code within malloc.

Note also that some functions, like strtok are not thread safe, so you need to use them with care, or use the thread safe equivalents of them.

I see that being stdlib a compiled library will never be able to access pvPortMalloc from heap_5, it seems to me that one way would be for stdlib’s required functions that use dynamic allocation to be rewritten within my application, which would ultimately only be strtok.
I appreciate the answers.

In my experience, you can redefine any function from the C standard library.
When you define your version of malloc(), it will be called from both strtok() or any other clib function.

The biggest issue with defining your own version of standard library functions (besides the fact that technically, it produces undefined behavior) is that you need to know a lot about the implementation to get it right. There may be related functions that have internal dependancies that need to be handled, and you can get functions that you think would be using that function, actually using an internal version instead. The OP commented about stroke calling malloc_r, which is newlib’s internal reentrant version of malloc.