bug#30193: crash in libotf

[handa]

In article <63zi57dpmv.fsf_-_@fencepost.gnu.org>, Glenn Morris <rgm@gnu.org> 
writes:

> Eli Zaretskii wrote:
> > The crash seems to be inside the libotf/libm17n-flt library; CC'ing
> > Handa-san who may have comments on this.
> >
> > Meanwhile, please make sure you have the latest versions of these
> > libraries installed.

> Still crashes with emacs-26 and latest m17n libs.
> (Ie libotf 0.9.13 from 2012 and the m17n 1.8 RC from 2017)

Sorry for being late.
I've just committed the attached fix to the CVS repository of libotf.
You can get the source by:
  % cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/m17n co libotf

I am going to release the new version of libotf within a few weeks.

---
K. Handa
handa@gnu.org

2018-01-23  K. Handa  <handa@gnu.org>

        * src/otfopen.c (read_class_def): Handle the case of
        f.f1.GlyphCount and f.f2.ClassRangeCount being 0 gracefully.

--- otfopen.c.~1.65.~   2015-03-27 15:14:46.000000000 +0900
+++ otfopen.c   2018-01-23 22:40:04.740168815 +0900
@@ -1040,8 +1040,6 @@
        = read_glyph_ids (otf, stream,
                          (OTF_GlyphID **) &class->f.f1.ClassValueArray,
                          0, -1);
-      if (! class->f.f1.GlyphCount)
-       return -1;
     }
   else if (class->ClassFormat == 2)
     {
@@ -1049,8 +1047,6 @@
        = read_range_records (otf, stream,
                              (OTF_RangeRecord **)
                              &class->f.f2.ClassRangeRecord);
-      if (! class->f.f2.ClassRangeCount)
-       return -1;
     }
   else
     OTF_ERROR (OTF_ERROR_TABLE, " (Invalid format)");