_REENT_CHECK_VERIFY calls __assert_func even if NDEBUG is defined

[R. Diez]

> If you're tight on RAM, you might look at the newlib fork, picolibc,
> which uses native TLS support for reentrant data values like
> _rand_next. With that approach, your thread-local storage contains only
> values used by your application and malloc need never be called. In this
> case, the per-thread data would be only eight bytes.

I do have one microcontroller with 8 KiB SRAM. For all others I do not want to bother.

I am interested in your "only eight bytes" claim. Say I use picolibc, and then my firmware wants to use rand(), which needs many more bytes for the 
state of the pseudo-random number generator.

The firmware is bare metal (no operating system). I guess there will not be a native TLS support then.

How does rand() get the memory it needs? Do I need to preallocate it statically? Or have a separate memory pool for the TLS? Do I need to implement 
TLS myself? Can you do that with some sort of easy-to-code stack?

Regards,
   rdiez