Re: _REENT_CHECK_VERIFY calls __assert_func even if NDEBUG is defined

[Jeff Johnston <jjohnstn@redhat.com>]

The code does not disable via NDEBUG because it is a fix for a CVE.  It is
not (and should not be) tied to user control over usage of the assert macro.

If you do not want the verification check, you can use
--disable-newlib-reent-check-verify when you configure.

-- Jeff J.

On Mon, Apr 27, 2020 at 11:58 AM R. Diez via Newlib <newlib@sourceware.org>
wrote:

> Hallo all:
>
> I have used Newlib 3.1.0 (and older versions) for quite some time. I am
> trying to upgrade to the latest release/snapshot 3.3.0, but I hit a
> compilation error in release builds (with NDEBUG defined):
>
> newlib-3.3.0/newlib/libc/stdlib/rand.c:78: undefined reference to
> `__assert_func'
>
> I tracked it down to this definition:
>
> /* Specify how to handle reent_check malloc failures. */
> #ifdef _REENT_CHECK_VERIFY
> #include <assert.h>
> #define __reent_assert(x) ((x) ? (void)0 : __assert_func(__FILE__,
> __LINE__, (char *)0, "REENT malloc succeeded"))
> #else
> #define __reent_assert(x) ((void)0)
> #endif
>
> This is unfortunate. First of all, I wonder what happens if malloc fails
> and there is no assert. Will there be a crash?
>
> Then, I would like to assert() in debug builds, and not in release builds.
> My code does not define __assert_func in release builds, because assertions
> are only supposed to work if NDEBUG is not defined. That has been working
> fine for years, until this Newlib version.
>
> I am configuring Newlib with --disable-newlib-multithread , because my
> embedded firmware has no threads. But I guess I still have to deal with
> "struct _reent", don't I? I would have hoped that, in this single-thread
> situation, any reentrancy structure could be allocated statically. Or is
> there any way to avoid this malloc()?
>
> Thanks in advance,
>   rdiez
>
>