>>>> Also, I just ran into the issue of `FT_Stream_OpenGzip' requiring >>>> the stream to having a valid `memory' field, which is not provided >>>> by `FT_Stream_OpenMemory' (for obvious reasons). >>> >>> This looks like a bug, both in documentation (which doesn't mention >>> it) and implementation (which doesn't correctly check for a valid >>> `memory' field). > > After some thinking I now believe that we have to solve this issue in a > different way. A stream should always be created with `FT_Stream_New'; among > other things it ensures that there is a valid `stream->memory' field. If you > encounter a situation where `memory' > is NULL it seems that either `FT_Stream_New' wasn't properly called, or > `stream' wasn't set up correctly. Can you investigate that?
If I'm not mistaken, one such place is http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/base/ftmac. c#n770 (this is where I got my initial idea from :)) ... there are generally a few more cases in combination with `FT_Stream_OpenMemory' and possibly more instances with other initialisation methods. Do you suggest patching those cases or just suggesting `FT_Stream_New' as "best practise" in the future? > So please commit the `memory' checks but not the documenation fix, which is an > internal detail Joe User shouldn't take care of (as Alexei correctly states). Tbh, I'm not sure how much these checks help; if you have half initialised (non-zeroed-out-first) objects from `FT_Stream_OpenMemory', these checks won't help (e.g. in `ftmac.c'). Afaik there's no policy about throwing half-initialised things at `FT_Stream_OpenMemory' (which does not zero-out anything either). These NULL-checks are only useful when used on properly initialised objects which, most likely, stem from `FT_Stream_New' anyways and don't need those checks. Please correct me where I'm wrong! :) Armin _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
