[HarfBuzz] scratch_buffer allocation bug in uniscribe backend

[Jonathan Kew]

My cygwin build kept aborting on certain test words when run with the 
uniscribe backend. Turned out this was caused by a bug in the allocation 
of scratch buffers in hb-uniscribe.cc.

Commit 2a17f9568d9724e045d2c1d660e007f3acd747d9 introduced a new line

   ALLOCATE_ARRAY (SCRIPT_VISATTR, vis_attr, glyphs_size);

but it failed to account for this in the computation of glyphs_size (the 
number of glyphs for which scratch buffer space is available), with the 
result that the vis_clusters array ends up overrunning the end of the 
scratch buffer and clobbering the beginning of the buffer's info[].

AFAICS, the vis_attr array is not actually used, so the simple fix is to 
remove the line that allocates it. (If/when we -do- need to use vis_attr 
for something, we'll need to add another term to the earlier calculation 
of glyphs_size.)

With this patch, the uniscribe backend runs reliably again.

JK
-------------- next part --------------
diff --git a/src/hb-uniscribe.cc b/src/hb-uniscribe.cc
index 2582ac6..4d27b9b 100644
--- a/src/hb-uniscribe.cc
+++ b/src/hb-uniscribe.cc
@@ -501,7 +501,6 @@ retry:
 
   ALLOCATE_ARRAY (WORD, glyphs, glyphs_size);
   ALLOCATE_ARRAY (SCRIPT_GLYPHPROP, glyph_props, glyphs_size);
-  ALLOCATE_ARRAY (SCRIPT_VISATTR, vis_attr, glyphs_size);
   ALLOCATE_ARRAY (int, advances, glyphs_size);
   ALLOCATE_ARRAY (GOFFSET, offsets, glyphs_size);
   ALLOCATE_ARRAY (uint32_t, vis_clusters, glyphs_size);