GrieferAtWork/tpp

Why API_FREE(p) free(p) is not used in the source code, there are still many free() function calls

asmwarrior opened this issue · 2 comments

I see there is a macro definition

#define API_FREE(p) free(p)

But the API_FREE(p) function call is not used all in the source code, there are still many free() function calls. Any reason about this?

Thanks.

PS: I'm still trying to find what causes the memory leak issue in the comment: #1 (comment)

Maybe, we can zero the pointer after the free(p) function call, so that

free(p);
p = NULL;

The difference is that API_FREE is only there for sugar and to go hand-in-hand with API_MALLOC. It is always the same as free().

However, there is a difference between API_MALLOC() and malloc(). When API_MALLOC() gets called and the allocation fails, a lexer error is set (TPPLexer_SetErr()) and the hook TPP_CONFIG_SET_API_ERROR_BADALLOC (if defined) is called if this is the first lexer error.

When some part of the code uses malloc() instead, that means that it intends to handle allocation errors itself, possibly in a way that won't trigger TPPLexer_SetErr().

I hope that answers your question why not all code uses "API_FREE()".

If your intend is to override heap functions before #include-ing tpp.c, just #define malloc() & friends instead, like I do here:
https://github.com/GrieferAtWork/deemon/blob/6cb80161d4c9d366fa28984d87fef770950dd02a/src/deemon/compiler/tpp.c#L120

Regarding this:

free(p);
p = NULL;

Sorry: that's not how I roll. If there are double-free bugs anywhere, in my book the solution isn't to work around them, but to fix them. (maybe even provoke them to happen more often by setting p to 0xCCCCCCCC instead of NULL when !defined(NDEBUG))