Usage of __assert_func in standard library

[Corinna Vinschen]

On Nov 18 19:13, Alex Tarasov wrote:
> Dear developers of  Newlib,
> 
> I think we have a bit of an issue concerning usage of *__assert_func *function
> in the current version of the standard library.
> [...]
> ld.exe: PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a(libc_a-closer.o):
> in function `_close_r':
> closer.c:(.text._close_r+0xc): undefined reference to `_close'
> [...]
> The analysis of cross reference table in the .map file showed me the source
> of these errors. Somehow, in the newer toolchain functions from the
> standard library (*strtod* in my case) call *"__assert_func"* which in turn
> lead to various system calls. I downloaded the latest Newlib version on the
> "main" branch and saw this code in the *newlib/libc/stdlib/mprec.h* file:
> 
> #define eBalloc(__reent_ptr, __len) ({ \
>    void *__ptr = Balloc(__reent_ptr, __len); \
>    if (__ptr == NULL) \
>      __assert_func(__FILE__, __LINE__, (char *)0, "Balloc succeeded"); \
>    __ptr; \
>    })
> 
> According to *git log* this *eBalloc* macro was introduced in commit
> with f88aece242178ff0c187d56e34a79645fbc44a23
> hash on October 4th 2019. This leads to several functions in the standard
> library calling *__assert_func* inside them. Standard definition of this
> function in *newlib/libc/stdlib/assert.c* calls *abort* and *fiprintf*
> functions
> which in turn drag a lot of system functions (see error log that I
> mentioned above).
> 
> This leads to several issues:
> 
>    - If I want to use some functions from the standard library (like
>    *strtod*) but I don't want any system calls, I need to redefine
>    *__assert_func* in my project. I have to do it even if I don't use
>    assert's anywhere in my own code.
>    - There is a project where I use <assert.h> and my own
> implementation of *__assert_func.
>    *I expect that when I build my project with NDEBUG macro defined
>    (release configuration), I would not see any calls to that function. That
>    is not the case if any function from Newlib's standard library that uses
>    *eBalloc* macro gets linked.
> 
> I think this behaviour is too implicit and needs to be fixed. I suggest
> removing *__assert_func* from *eBalloc* macro or making some other changes
> to Newlib that will get rid of the mentioned issues.

Yeah, that looks a tad too aggressive.

I see only ~20 calls to eBalloc in newlib.  Maybe somebody can take
a stab at it and convert the calls to Balloc plus error checking?

However, the parent functions of the functions calling eBalloc
potentially don't check error conditions either, so this might be indeed
a bit more work than a quick count of the eBalloc calls indicates...

Jeff? Any idea how to go forward?


Corinna