#3 libg15render.h depends on internal config.h to work
Situation: an application includes libg15render.h,
thinking to use the g15render library. It allocates
some memory of sizeof(g15canvas) (which seems to be the
official way to allocate such structures), then tries
to initialize it with g15r_initCanvas.
However, libg15render was compiled with FreeType. The
header file, during the compilation of the application,
doesn't see a TTF_SUPPORT define because the internal
config.h isn't there, so it happily fails to include the
TTF stuff in the structure declaration and therefore
in the structure size. The library, of course, compiled
with the TTF stuff in it.
Whoops. Now the application thinks the structure is
smaller than the library thinks it is, and the library
is now writing outside the structure the application
allocated. Fandango on core.
Solution: add size_t g15canvas_sizeof(void) to the
library or something, perhaps. Ideally the structure
members should be private and the client should only
ever see opaque references.
Logged In: YES
user_id=444162
Originator: NO
I'm sorry for taking so long to address this issue. I've moved the TTF initialization stuff to g15r_initTTFCanvas that programs wishing to use TTF support can use in place of g15r_initCanvas. I've also moved the freetype members of g15canvas into a new g15_ttf_canvas and made g15canvas->ttf_canvas a pointer to one of those. This should ensure that g15canvas is a fixed size regardless whether TTF_SUPPORT is enabled or not. This should hopefully minimize the impact on consumers of libg15render, requiring a simple recompile if not using TTF features and adding a call to g15r_initTTFCanvas if they do use TTF. g15canvas->ttf_canvas is allocated in g15r_initTTFCanvas, so it's necessary to free it before you free g15canvas when using TTF_SUPPORT.
Logged In: NO
That doesn't imply that the structure will never change in future versions of the library, though. Expecting the user of the library to allocate using static sizeof makes binary compatibility difficult, because it basically means API compatibility breaks between any two versions with different structure sizes. So I would still recommend making the API more robust on that front.
But---contrariwise to your initial statement---thank you for responding so quickly to this. I would hardly expect projects like this to have single-day turnaround times or anything like that. :-)
Logged In: YES
user_id=444162
Originator: NO
You're right, in a future version I intend to replace g15r_initCanvas with a function that allocates and returns a g15canvas struct rather than expecting the user to allocate it. I'll probably also add JavaBeans style accessors for the members of the struct, which should hopefully allow the struct to change without requiring recompilation. My initial concern was to minimize the changes necessary to client programs, but since I can probably count them on one hand at this point, it might be better just to do it now. This is my first attempt at creating a library intended to be used by others, so I've probably made some other design errors, if you have any more suggestions they'd be greatly appreciated.
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).