bug#17881: 24.4.50; decoding by emacs-mule hangs up

[K. Handa]

In article <83wqby4d8m.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> Fixed in trunk revision 117451.

Thank you for the quick fix!
But, considering the usage of coding->charbuf, I think the
following fix is better.  It always allocates 16 units more
in coding->charbuf.  So, as far as it doesn't reach
MAX_CHARBUF_SIZE, decoding routines never stop by
insufficient coding->charbuf.  I'm going to install it as
soon as I finish several tests.

=== modified file 'src/coding.c'
--- src/coding.c        2014-06-28 13:38:36 +0000
+++ src/coding.c        2014-07-01 15:27:35 +0000
@@ -7266,13 +7266,17 @@
 }
 
 #define MAX_CHARBUF_SIZE 0x4000
-#define MIN_CHARBUF_SIZE 0x10
+/* How many units decoding functions expect in coding->charbuf at
+   most.  Currently, decode_coding_emacs_mule expects the following
+   size, and that is the largest value.  */
+#define MAX_CHARBUF_EXTRA_SIZE ((MAX_ANNOTATION_LENGTH * 3) + 1)
 
 #define ALLOC_CONVERSION_WORK_AREA(coding, size)               \
   do {                                                         \
-    int units = ((size) > MAX_CHARBUF_SIZE ? MAX_CHARBUF_SIZE  \
-                : (size) < MIN_CHARBUF_SIZE ? MIN_CHARBUF_SIZE \
-                : size);                                       \
+    int units = (size) + MAX_CHARBUF_EXTRA_SIZE;               \
+                                                               \
+    if (units > MAX_CHARBUF_SIZE)                              \
+      units = MAX_CHARBUF_SIZE;                                        \
     coding->charbuf = SAFE_ALLOCA ((units) * sizeof (int));    \
     coding->charbuf_size = (units);                            \
   } while (0)