>> IMHO, `FT_Done_Face' shouldn't return an error code
>> at all.
>
> Glad you finally agree. So how to fix it?
IMHO, there is nothing to fix.
> * For backward compability, it should continue to return FT_Err_Ok.
It should return what it already returns.
> * So what should the code do if the FT_List_Find call returns NULL?
> I think it should print a message to stderr and abort the program.
I don't want that. I still think that a library should return control
to the caller even if something weird is happening. Just imagine a
Windows program where output to stderr is not displayed. You rather
have to give control back to Windows so that it can create a useful
dialogue window.
> Ignoring the internal consistency failure is not really a good idea.
> It is very likely an indication that memory blocks are screwed. So
> if the code just tries to keep going, it could hit a segfault later
> on, or otherwise behave unpredictably.
Why do you think, from a user's point of view, that aborting is better
than segfaulting? In both cases the point of failure is not where the
error gets triggered. Only a tool like `valgrind' can give more
information to find out where the memory got corrupted.
> And then the programmer is left scratching their head as to what
> went wrong. By reporting the problem as close as possible to the
> point of its discovery, you maximize the chance that it can be found
> and fixed.
I don't think so. If you get a crash, the first action usually is to
run the program within a debugger or a tool like `valgrind' (assuming
you have compiled with activated debugging support).
What I can imagine, however, is to add `assert' statements. FreeType
has very few of them; maybe there should be more to better check
consistency.
Werner
_______________________________________________
Freetype mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype
