Support custom malloc()/free() for memory allocation

[raysan5]

Similar to stb libraries, it would be nice to support custom memory allocators:

#if defined(CGLTF_MALLOC) && defined(CGLTF_FREE)
// ok
#elif !defined(CGLTF_MALLOC) && !defined(CGLTF_FREE) 
// ok
#else
#error "Must define both or none of CGLTF_MALLOC and CGLTF_FREE
#endif

#ifndef CGLTF_MALLOC
#define CGLTF_MALLOC(sz)       malloc(sz)
#define CGLTF_FREE(p)          free(p)
#endif

[LxLasso]

Take a look at the contents of cgltf_options, a struct that is passed to cgltf_parse. It has two fields, memory_alloc and memory_free that I think is what you're looking for?

[raysan5]

@LxLasso thanks for the answer! Yes, that's an option for custom allocators but calling malloc() and free() in cgltf_default_alloc() and cgltf_default_free() forces to link with a library providing those symbols (stdlib).

[LxLasso]

I see @raysan5 . In that case there's an include for stdlib.h to get rid of as well. A hackaround for not having to link stdlib could be providing your own malloc and free symbols though?

[raysan5]

@LxLasso actually, there are also a couple of calls to atoi() and atof() that require stdlib, but they could also be replaced with custom implementations if required.

A hackaround for not having to link stdlib could be providing your own malloc and free symbols though?

Using a macro like the one I mention and replacing malloc() by CGLTF_MALLOC() would be enough to avoid symbols requirement (when user overrides macro in user code):

#ifndef CGLTF_MALLOC
#define CGLTF_MALLOC(sz)   malloc(sz)
#define CGLTF_FREE(p)      free(p)
#endif

Users can just define the macro in their code:

#define CGLTF_MALLOC(sz)    custom_malloc(sz)
#define CGLTF_FREE(p)       custom_free(p)

#define CGLTF_IMPLEMENTATION
#include "cgltf.h"          // malloc()/free() symbols never defined, stdlib not required

[jkuhlmann]

So, do I get this right, your goal is to get rid of the stdlib dependency?

[raysan5]

@jkuhlmann Actually the goal is having a mechanism to not only allow custom allocator but also avoid system dependencies to default ones. It's just to increase a bit library portability.

Here it is my related issue: raysan5/raylib#1074

[jkuhlmann]

@raysan5, does something like PR #99 fit the bill?

[raysan5]

@jkuhlmann that's perfect! thank you very much for implementing it! 👍😄