<div dir="ltr"><div>That's similar to what I originally had, so I'm fine with something like that. My only question is, what would <font face="monospace, monospace">hb_malloc_impl</font>, <font face="monospace, monospace">hb_calloc_impl</font>, <font face="monospace, monospace">hb_realloc_impl</font>, and <font face="monospace, monospace">hb_free_impl</font> be defined to in your example?</div><div><br></div><div>I went with the <font face="monospace, monospace">extern</font> function approach so I could inject my own allocator functions into HarfBuzz at link time, rather than have to include any of our code into HarfBuzz at compile time (since any local code changes we make have to be re-applied against new versions).</div><div><br></div><div>For your reference, this was my original implementation:</div><div><br></div><div><font face="monospace, monospace">/* Override the allocation functions when </font></div><div><font face="monospace, monospace"> * HAVE_EXTERNAL_ALLOCATOR is defined. */</font></div><div><font face="monospace, monospace">#ifdef HAVE_EXTERNAL_ALLOCATOR</font></div><div><font face="monospace, monospace">extern void* _hb_malloc(size_t);</font></div><div><font face="monospace, monospace">extern void* _hb_calloc(size_t, size_t);</font></div><div><font face="monospace, monospace">extern void* _hb_realloc(void*, size_t);</font></div><div><font face="monospace, monospace">extern void _hb_free(void*);</font></div><div><font face="monospace, monospace">#define malloc _hb_malloc</font></div><div><font face="monospace, monospace">#define calloc _hb_calloc</font></div><div><font face="monospace, monospace">#define realloc _hb_realloc</font></div><div><font face="monospace, monospace">#define free _hb_free</font></div><div><font face="monospace, monospace">#endif</font></div><div><br></div><div>Failure to define those functions in something that linked to HarfBuzz would produce an unresolved external symbol error at link time.</div><div><br></div><div>-Jamie.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 2 October 2015 at 08:08, Behdad Esfahbod <span dir="ltr"><<a href="mailto:behdad.esfahbod@gmail.com" target="_blank">behdad.esfahbod@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jamie,<br>
<br>
I'm opposed to runtime custom allocators, but am fine with something like what<br>
you suggest.  However, that has two down sides:<br>
<br>
  1. It touches a lot of callsites,<br>
<br>
  2. I have to add macros to make sure stock malloc etc are not used by mistake.<br>
<br>
If doing 2., I might as well just define them to their custom behavior.  Ie,<br>
would this patch work for you:<br>
<br>
diff --git a/src/hb-private.hh b/src/hb-private.hh<br>
index 07550cb..167c067 100644<br>
--- a/src/hb-private.hh<br>
+++ b/src/hb-private.hh<br>
@@ -54,6 +54,19 @@<br>
 #include <stdarg.h><br>
<br>
<br>
+/* Compile-time custom allocator support. */<br>
+<br>
+#if defined(hb_malloc_impl) \<br>
+ && defined(hb_calloc_impl) \<br>
+ && defined(hb_realloc_impl) \<br>
+ && defined(hb_free_impl)<br>
+#define malloc hb_malloc_impl<br>
+#define calloc hb_calloc_impl<br>
+#define realloc hb_realloc_impl<br>
+#define free hb_free_impl<br>
+#endif<br>
+<br>
+<br>
 /* Compiler attributes */<br>
<div><div class="h5"><br>
<br>
<br>
<br>
On 15-09-30 03:49 PM, Jamie Dale wrote:<br>
> Since there was no movement here I went ahead and hacked in our allocator by<br>
> redefining malloc, calloc, realloc, and free to point to extern'd functions<br>
> that I define in our application. This yielded some performance benefits for<br>
> us, so I'm hoping that a more standard HarfBuzz solution might appear at some<br>
> point :)<br>
><br>
> If you're not keen on the idea of allowing the allocator to be swapped out at<br>
> runtime, would you at least allow it to be extern'd at compile time? I'm not<br>
> familiar with HarfBuzz coding standards, but I'd propose adding something like<br>
> a HAVE_EXTERNAL_ALLOCATOR define to control this, and then define your own<br>
> allocator functions that you'd use in place of malloc, etc.<br>
><br>
> Basically, something like this (I currently have this code in hb-private.hh):<br>
><br>
> /* Define our allocation functions. These may be provided by an<br>
>  * external source when HAVE_EXTERNAL_ALLOCATOR is defined. */<br>
> #ifdef HAVE_EXTERNAL_ALLOCATOR<br>
> extern void* _hb_malloc(size_t);<br>
> extern void* _hb_calloc(size_t, size_t);<br>
> extern void* _hb_realloc(void*, size_t);<br>
> extern void _hb_free(void*);<br>
> #define hb_malloc _hb_malloc<br>
> #define hb_calloc _hb_calloc<br>
> #define hb_realloc _hb_realloc<br>
> #define hb_free _hb_free<br>
> #else<br>
> #define hb_malloc malloc<br>
> #define hb_calloc calloc<br>
> #define hb_realloc realloc<br>
> #define hb_free free<br>
> #endif<br>
><br>
> You'd then replace calls to malloc, calloc, realloc, and free from within<br>
> HarfBuzz to use hb_malloc, hb_calloc, hb_realloc, and hb_free.<br>
><br>
> This is basically the code I already have, except I<br>
> redefined malloc, calloc, realloc, and free rather than create the<br>
</div></div>> hb_*variants, as I didn't want to change too much HarfBuzz code.<br>
<span class="">><br>
> Thoughts?<br>
><br>
> On 31 August 2015 at 22:17, Jamie Dale <<a href="mailto:jamiedale88%2Bharfbuzz@gmail.com">jamiedale88+harfbuzz@gmail.com</a><br>
</span><span class="">> <mailto:<a href="mailto:jamiedale88%2Bharfbuzz@gmail.com">jamiedale88+harfbuzz@gmail.com</a>>> wrote:<br>
><br>
>     Hey,<br>
><br>
>     I'm not sure if this is correct place to post/discuss feature requests...<br>
>     hopefully it is.<br>
><br>
>     Our project makes use of a custom memory allocator, and we like to ensure<br>
>     that our third-party libraries are using this where possible, as our<br>
>     allocator can offer significantly better performance, and can also allow<br>
>     us better memory profiling and debugging support.<br>
><br>
>     A look through the HarfBuzz source code would suggest that it doesn't<br>
>     currently support custom memory allocators, and instead just directly<br>
>     calls the standard malloc/free/etc functions. I was wondering if you'd<br>
>     ever considered (or would consider) adding a way to override this behaviour?<br>
><br>
>     In my case, I'd just need a single global override to be set before my<br>
>     first call to any other HarfBuzz code... basically something like<br>
>     the FT_Memory struct from FreeType:<br>
>     <a href="http://www.freetype.org/freetype2/docs/reference/ft2-system_interface.html#FT_Memory" rel="noreferrer" target="_blank">http://www.freetype.org/freetype2/docs/reference/ft2-system_interface.html#FT_Memory</a><br>
><br>
>     Thanks,<br>
>     Jamie.<br>
><br>
><br>
><br>
><br>
</span>> _______________________________________________<br>
> HarfBuzz mailing list<br>
> <a href="mailto:HarfBuzz@lists.freedesktop.org">HarfBuzz@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/harfbuzz" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/harfbuzz</a><br>
><br>
</blockquote></div><br></div>