<div dir="ltr">Just tested this against another test app I have (not mine, a demo app that's written in C) and it failed to link as it was looking for the C++ named-mangled versions of those externed functions. They should probably be declared with <font face="monospace, monospace">extern "C"</font> around them so that they can be defined by C applications.<div><br></div><div>In hindsight I should have mentioned this before, however I'd always assumed HarfBuzz was a C library due to the way its API is designed, but the templates in the OT font code proves otherwise :)</div><div><br></div><div>-Jamie.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 5 October 2015 at 19:58, Jamie Dale <span dir="ltr"><<a href="mailto:jamiedale88+harfbuzz@gmail.com" target="_blank">jamiedale88+harfbuzz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Just tested this and it worked fine. Thanks :)</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 3 October 2015 at 13:20, 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"><span>On 15-10-02 10:00 PM, Jamie Dale wrote:<br>
> That's similar to what I originally had, so I'm fine with something like that.<br>
> My only question is, what would hb_malloc_impl, hb_calloc_impl,<br>
> hb_realloc_impl, and hb_free_impl be defined to in your example?<br>
<br>
</span>Define it to the name of your external function.  I don't want to fix a name<br>
in HarfBuzz itself.  Updated patch to add externs:<br>
<br>
diff --git a/src/hb-private.hh b/src/hb-private.hh<br>
index 07550cb..826e41a 100644<br>
--- a/src/hb-private.hh<br>
+++ b/src/hb-private.hh<br>
@@ -54,6 +54,23 @@<br>
<span> #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>
</span>+extern void* hb_malloc_impl(size_t size);<br>
+extern void* hb_calloc_impl(size_t nmemb, size_t size);<br>
+extern void* hb_realloc_impl(void *, size_t size);<br>
+extern void  hb_free_impl(void *ptr);<br>
<span>+#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>
</span>I'll go ahead and commit this.  Let me know if it doesn't work.<br>
<span><br>
> I went with the extern function approach so I could inject my own allocator<br>
> functions into HarfBuzz at link time, rather than have to include any of our<br>
> code into HarfBuzz at compile time (since any local code changes we make have<br>
> to be re-applied against new versions).<br>
><br>
> For your reference, this was my original implementation:<br>
><br>
> /* Override the allocation functions when<br>
>  * 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 malloc _hb_malloc<br>
> #define calloc _hb_calloc<br>
> #define realloc _hb_realloc<br>
> #define free _hb_free<br>
> #endif<br>
><br>
> Failure to define those functions in something that linked to HarfBuzz would<br>
> produce an unresolved external symbol error at link time.<br>
><br>
> -Jamie.<br>
><br>
> On 2 October 2015 at 08:08, Behdad Esfahbod <<a href="mailto:behdad.esfahbod@gmail.com" target="_blank">behdad.esfahbod@gmail.com</a><br>
</span><div><div>> <mailto:<a href="mailto:behdad.esfahbod@gmail.com" target="_blank">behdad.esfahbod@gmail.com</a>>> wrote:<br>
><br>
>     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<br>
>     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>
><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<br>
>     some<br>
>     > point :)<br>
>     ><br>
>     > If you're not keen on the idea of allowing the allocator to be swapped<br>
>     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<br>
>     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<br>
>     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>
>     > hb_*variants, as I didn't want to change too much HarfBuzz code.<br>
>     ><br>
>     > Thoughts?<br>
>     ><br>
</div></div>>     > On 31 August 2015 at 22:17, Jamie Dale <<a href="mailto:jamiedale88%2Bharfbuzz@gmail.com" target="_blank">jamiedale88+harfbuzz@gmail.com</a> <mailto:<a href="mailto:jamiedale88%252Bharfbuzz@gmail.com" target="_blank">jamiedale88%2Bharfbuzz@gmail.com</a>><br>
>     > <mailto:<a href="mailto:jamiedale88%2Bharfbuzz@gmail.com" target="_blank">jamiedale88+harfbuzz@gmail.com</a> <mailto:<a href="mailto:jamiedale88%252Bharfbuzz@gmail.com" target="_blank">jamiedale88%2Bharfbuzz@gmail.com</a>>>><br>
<span>>     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>
>     > _______________________________________________<br>
>     > HarfBuzz mailing list<br>
</span>>     > <a href="mailto:HarfBuzz@lists.freedesktop.org" target="_blank">HarfBuzz@lists.freedesktop.org</a> <mailto:<a href="mailto:HarfBuzz@lists.freedesktop.org" target="_blank">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>
><br>
><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>