bug#9496: 24.0.50; Segfault on TAB-only composition

[Paul Eggert <eggert@cs.ucla.edu>]

When a fix for this was merged into the trunk I noticed a problem from the
trunk's point of view: the fix introduced the possibility of an unchecked
integer overflow which would cause character widths to go negative
and could cause real problems later.  I installed this further fix
to the trunk:

Handle overflow when computing char display width (Bug#9496).
* character.c (char_width): Return EMACS_INT, not int.
(char_width, c_string_width): Check for overflow when
computing the width; this is possible now that individual
characters can have unbounded width.  Problem introduced
by merge from Emacs 23 on 2012-01-19.
=== modified file 'src/character.c'
--- src/character.c	2012-01-19 07:21:25 +0000
+++ src/character.c	2012-02-03 19:19:42 +0000
@@ -311,10 +311,10 @@

 /* Return width (columns) of C considering the buffer display table DP. */

-static int
+static EMACS_INT
 char_width (int c, struct Lisp_Char_Table *dp)
 {
-  int width = CHAR_WIDTH (c);
+  EMACS_INT width = CHAR_WIDTH (c);

   if (dp)
     {
@@ -326,7 +326,12 @@
 	  {
 	    ch = AREF (disp, i);
 	    if (CHARACTERP (ch))
-	      width += CHAR_WIDTH (XFASTINT (ch));
+	      {
+		int w = CHAR_WIDTH (XFASTINT (ch));
+		if (INT_ADD_OVERFLOW (width, w))
+		  string_overflow ();
+		width += w;
+	      }
 	  }
     }
   return width;
@@ -340,7 +345,8 @@
 usage: (char-width CHAR)  */)
   (Lisp_Object ch)
 {
-  int c, width;
+  int c;
+  EMACS_INT width;

   CHECK_CHARACTER (ch);
   c = XINT (ch);
@@ -367,10 +373,14 @@
     {
       int bytes;
       int c = STRING_CHAR_AND_LENGTH (str + i_byte, bytes);
-      int thiswidth = char_width (c, dp);
+      EMACS_INT thiswidth = char_width (c, dp);

-      if (precision > 0
-	  && (width + thiswidth > precision))
+      if (precision <= 0)
+	{
+	  if (INT_ADD_OVERFLOW (width, thiswidth))
+	    string_overflow ();
+	}
+      else if (precision - width < thiswidth)
 	{
 	  *nchars = i;
 	  *nbytes = i_byte;