bug#25945: Emacs aborts while calling FT_Load_Glyph

[Eli Zaretskii]

> Date: Fri, 03 Mar 2017 11:37:06 +0100 (CET)
> Cc: handa@gnu.org, 25945@debbugs.gnu.org
> From: Werner LEMBERG <wl@gnu.org>
> 
> >> > I think it's too late for (b) when we discover this problem in
> >> > ftfont_get_metrics.  To do (b) we should have discovered this in
> >> > ftfont_has_char, or thereabouts.
> >> 
> >> Interesting.  How comes that Emacs aborts right there?
> > 
> > Sorry, I don't understand the question.  If you are asking why
> > there's a call to emacs_abort if FT_Load_Glyph fails, then I guess
> > it''s because this is unexpected and we have no code capable of
> > coping with such a calamity.
> 
> I mean: There's more than one place where FT_Load_Glyph is called with
> `FT_LOAD_DEFAULT'.  You say that it is `too late'; this implies that
> FT_Load_Glyph' has already been called earlier for a given glyph (with
> `FT_LOAD_DEFAULT'), apparently without any fatal causes.

No, it's "too late" because by the time ftfont_get_metrics is called,
Emacs has already established that the particular character is
supported by this font, and ftfont_get_metrics doesn't provide a way
to tell the caller that the character is not supported.  IOW, all the
fallbacks that look for an alternative font don't assume (AFAIK) that
a failure to display a character by some font can be discovered that
late.

> There's just a single `emacs_abort' related to the calls to
> FT_Load_Glyph, and this looks strange to me – and not justified.

It could be a problem, indeed.  But it could also be that all of those
other calls are either (a) after this particular one, so they will
never be made if this one fails, or (b) they have a way of
communicating a failure to their caller.

IOW, one must analyze these calls in the context of the control flow
when accessing a font for displaying a character, to understand
whether this single call to emacs_abort is enough.