Re: allocate_string_data memory corruption

[Chong Yidong <cyd@stupidchicken.com>]

>> Please remind me why we don't use SYNC_INPUT by default
>
> ... it supposedly may delay the processing of C-g since we then
> processs signals with a "polling" model (if we get stuck in a loop
> with no QUIT and no BLOCK_INPUT we won't ever process the C-g.  It
> seems to be that even without SYNC_INPUT, under X11, a C-g is not
> process until we reach a QUIT, so the difference is not clear to
> me).

How about this idea...

The problem is that the X signal handler (XTread_socket) does stuff
that can clobber the heap.  Richard's objection to SYNC_INPUT is that
C-g may not be read in some loops.  But Stefan pointed out that under
X, C-g is not processed until we read a QUIT.

My proposal is to make signal handling work like SYNC_INPUT when we
are running in X (i.e., when read_socket_hook is NULL).  The C-g
behavior is no worse than before, and the terminal behavior remains
the same as before.  We lose nothing, while resolving the memory
clobberage bugs.

This change would look something like this:


*** emacs/src/keyboard.c.~1.847.~	2006-01-20 10:05:43.000000000 -0500
--- emacs/src/keyboard.c	2006-01-24 22:12:26.000000000 -0500
***************
*** 6897,6903 ****
      EMACS_SET_SECS_USECS (*input_available_clear_time, 0, 0);
  
  #ifndef SYNC_INPUT
!   handle_async_input ();
  #endif
  
  #ifdef BSD4_1
--- 6897,6904 ----
      EMACS_SET_SECS_USECS (*input_available_clear_time, 0, 0);
  
  #ifndef SYNC_INPUT
!   if (!read_socket_hook)
!     handle_async_input ();
  #endif
  
  #ifdef BSD4_1
*** emacs/src/lisp.h.~1.547.~	2005-12-11 15:37:36.000000000 -0500
--- emacs/src/lisp.h	2006-01-24 22:13:41.000000000 -0500
***************
*** 1830,1835 ****
--- 1830,1837 ----
  	  Fthrow (Vthrow_on_input, Qt);			\
  	Fsignal (Qquit, Qnil);				\
        }						\
+     else if (!read_socket_hook)                       \
+       handle_async_input ();                          \
    } while (0)
  
  #endif	/* not SYNC_INPUT */