Re: _REENT_CHECK_VERIFY calls __assert_func even if NDEBUG is defined

["R. Diez" <rdiezmail-newlib@yahoo.de>]

 > [...]
> Regarding the _REENT_CHECK_VERIFY macro, this only affects you if you are using _REENT_SMALL.

I have been looking around further.

I have come to the conclusion that advertising configuration option "--enable-newlib-reent-small" as "enable small reentrant struct support" is 
actually doing a disservice to Newlib's users, especially in an embedded environment.

Those surprising calls to malloc() have a performance impact, as malloc() can be slow. They also cause safety issues, because of the unexpected extra 
memory consumption (memory is sometimes painstakingly accounted for). After all, there has already been a CVE in this area, and memory exhaustion at 
this unexpected place will crash the firmware. There is a further issue: malloc() is not safe everywhere (like inside an interrupt routine).

Therefore, I believe the only right thing to do is to place a warning next to that configuration option. For example, something like "warning: causes 
hidden malloc()'s on first touch" should suffice.


> With that set-up, the reentrant structure is minimal to start with and
> storage is allocated at the last minute, if needed.  If you look in libc/sys/reent.h
 > you will see that for the non _REENT_SMALL configuration, the
 > [...]

OK, thanks for confirming this.

There is no libc/sys/reent.h as far as I can tell. Confusingly, there are 2 files with the same name in Newlib:

newlib/libc/include/reent.h
newlib/libc/include/sys/reent.h

I guess you are referring to the second one. For convenience, it's here:

https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/sys/reent.h

I looked inside, and I do not understand why struct _reent has to be 1064 bytes long. There is space for __FILE structures, but my firmware is not 
using the STDIO routines at all. I am configuring with --disable-newlib-io-float, --disable-newlib-iconv , etc., so my guess is that many of the 
members inside struct _reent will never be used and could be optimised away with #if statements.

You could even configure the rand() data away if you can live with the weaker rand_r() variant.

There are some comments there about trying to maintain binary compatibility. Is this something that Cygwin needs? At least in an embedded environment 
there is no need for that. I thought that struct _reent is something internal to Newlib, or are there public fields meant for the library user?

Note that the size of this structure is not always the same. For example, member "_atexit" depends on "#ifndef _REENT_GLOBAL_ATEXIT". Therefore, this 
structure already varies in length today.


> So, you have a number of choices:
> 
> 1. don't use _REENT_SMALL and rand() won't allocate storage when used
> 2. use _REENT_SMALL but call rand() at the start of your application so it won't try to allocate memory later on
> 3. use _REENT_SMALL and ensure you have enough extra storage allocated to handle the apps needs and the minimal storage needed for the rand48 logic
> 4. allow the abort or null pointer access to occur and tune the application not to run into this scenario if it does happen

This is an excellent summary about dealing with configuration option "--enable-newlib-reent-small". Is there any chance it could make it to the Newlib 
documentation?

Best regards,
   rdiez