GNU bug report logs - #30193
crash in libotf

Previous Next

Full log

View this message in rfc822 format

From: handa <handa <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 30193 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: bug#30193: crash in libotf
Date: Tue, 23 Jan 2018 23:30:24 +0900

In article <63zi57dpmv.fsf_-_ <at> fencepost.gnu.org>, Glenn Morris <rgm <at> 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 <at> 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 <at> gnu.org

2018-01-23  K. Handa  <handa <at> 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)");

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.