<story><title>Minimalist C Libraries</title><url>http://nullprogram.com/blog/2018/06/10/</url></story><parent_chain></parent_chain><comment><author>xtrapolate</author><text>&amp;gt; &amp;quot;The library mustn’t call malloc() internally. It’s up to the caller to allocate memory for the library. What’s nice about this is that it’s completely up to the application exactly how memory is allocated. Maybe it’s using a custom allocator, or it’s not linked against the standard library.&amp;quot;&lt;p&gt;OP&amp;#x27;s approach will indeed work for most &amp;quot;minimalist&amp;quot;&amp;#x2F;single-header libraries, but, I personally feel it pollutes the API you&amp;#x27;re exposing to your users.&lt;p&gt;Depending on the specific situation, I may sometimes choose to expose a MODULE_CreateObject() and a MODULE_CreateObjectEx(custom_allocator, custom_deallocator).&lt;p&gt;Internally, MODULE_CreateObject() calls MODULE_CreateObjectEx(), passing the module&amp;#x27;s default allocators and deallocators (ie. HeapAlloc and HeapFree). This strikes me as a more balanced approach.&lt;p&gt;One caveat here, is that you must enforce consistency across usage - you don&amp;#x27;t want some API calls to use malloc() for allocation, whilst others use HeapFree() for deallocation, that would be a recipe for disaster.&lt;p&gt;To ensure that, I would often set the allocators and deallocators once, when the object is first created. They may be set through the object&amp;#x27;s initialization function, and they persist as part of the object itself.</text></comment>
<story><title>Minimalist C Libraries</title><url>http://nullprogram.com/blog/2018/06/10/</url></story><parent_chain></parent_chain><comment><author>panic</author><text>These “single-file libraries” share a lot of the same ideals: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;nothings&amp;#x2F;single_file_libs&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;nothings&amp;#x2F;single_file_libs&lt;/a&gt;</text></comment>