bug#12823: Invalid font name

[Kenichi Handa]

In article <jwvip8r6qe1.fsf-monnier+emacs@gnu.org>, Stefan Monnier 
<monnier@iro.umontreal.ca> writes:

> > For fixing this bug, I've just installed this change to
> > trunk (rev. 111019).

> Thanks, that looks good.

> > But, as the bug had caused crashing,
> > it may be better to apply the change to emacs-24.

> I didn't see any crashes, only assertion violations.
> FWIW Debian's emacs23 and emacs24 binaries don't crash here, so
> I suspect that the bug is luckily "solved" by accident somewhere.

You wrote;

> After letting xft use bitmap fonts on my system, Emacs started to crash,
> which was tracked to an invalid font name that was used
> without checking.
> So I added

>         if (NILP (spec))
>           signal_error ("Invalid font name", ascii_font);

> to x_set_font in revno 110704, but this only prevents the crash,
> replacing it with an error.

Do you mean this workaround as "assertion violations"?  I
think it just hides the deeper bug.  Here, SPEC is a return
value of font_spec_from_name (fontset_ascii (fontset)), and
font_spec_from_name should never fail with that kind of
argument.

> I'm still wondering about those names that include -, such as
> "semi-condensed" that we have in font.c:
> - IIUC, they can never be useful for XFLD font names.  Are they useful
>   for other font name formats supported by Emacs?  Examples?
> - If they are useful sometimes, is it important to have the dashed
>   name first in the list?

As I wrote before, the table is also used to get a face
attribute value from a font spec, and, for instance, face
attribute :width allows the symbol `semi-condensed'.  If we
don't have that name first in the list, we must have another
index specifying which name is a valid face attribute value,
or must have another tables that map numeric values of font
spec to face attribute values.

---
Kenichi Handa
handa@gnu.org