libg15render.h should not depend on its "caller" defining TTF_SUPPORT
First of all great to see that libg15render appears to have a new active upstream.
In lcdproc's g15 LCD panel code we have the following:
/*
* If we have freetype2, assume libg15render is build with TTF support,
* the TTF_SUPPORT define makes the size of the g15 struct bigger, if we do
* not set this define while libg15render is build with TTF support we get
* heap corruption. The other way around does not matter, then we just alloc
* a little bit too much memory (the TTF related variables live at the end
* of the struct).
*/
#ifdef HAVE_FT2
#define TTF_SUPPORT
#endif
#include <libg15render.h>
Recently we received a bug report from a user who is building lcdproc from sources, using its distro's libg15render-devel packages and while not having freetype-devel installed, causing lcdproc's configure to not set HAVE_FT2, so TTF_SUPPORT was not set when including libg15render.h which leads to a too small sizeof(struct g15canvas) leading to crashes, see: https://github.com/lcdproc/lcdproc/issues/188
Which is why I'm filing this issue, libg15render.h (or any header in /usr/include really) should not depend on its includer defining TTF_SUPPORT or not.
Since the TTF_SUPPORT define must match the way that lib15render was build to avoid bad things from happening, what really should be done is have a libg15render.h.in which gets processed by its ./configure script and which then generates a libg15render.h without the #ifdef-s which matches the compile time config of libg15render.
Note the change to using a libg15render.h.in should also get rid of the including "config.h" because including another project's config.h inside your public headers also really is not a good idea.