Where stdin/stdout/stderr pointers are allocated

[Rob Meades]

We run our own library of driver C code on several microcontroller platforms (e.g. STM32F4 and nRF5) where the SDK provided by the chip vendor uses newlib [pre-built by the vendor or by GCC] and FreeRTOS.  We use dynamically allocated tasks in the driver code and so, in our unit tests, we check for memory leaks to make sure we're shutting them down correctly.  FreeRTOS is sufficiently aware of newlib to call _reclaim_reent when a task exits.

The vendors do _not_ define _REENT_GLOBAL_STDIO_STREAMS and so each dynamic task ends up allocating file pointers for stdin/stdout/stderr.  As we understand it these are allocated in a _GLOBAL_REENT and not _REENT and, when a task exits, the file pointers are marked as free but not actually free'd so that they can be re-used later.

The problem then is that, since the file pointers are not being cleaned up when a dynamic task exits, our code "leaks" memory.  It is not _really_ a leak since the pointers are usable later by our driver code but it is taking memory from the customer's application that is not being returned.

QUESTION: is this how it is meant to work, stdin/stdout/stderr allocated in a global pool rather then in _REENT where FreeRTOS would free them on task exit?

If so our workaround, at least when unit testing, is to allocate a load of file pointers in a "preamble" test to take them out of our heap-checking equation.

Rob