[Patch 21.4] native cygwin xemacs-21.4.19 segfaults when requiring un-define

[Vin Shelton]

Comments?

Does anyone think the below patch will have a noticeable effect on
the speed byte compiler?  Barring any concerns, I will check this in for
21.4.20.

  - Vin

Aidan Kehoe <kehoea at parhasard.net> writes:

>  Ar an t-aonú lá is triochad de mí Iúil, scríobh Stephen J. Turnbull: 
>
>  > The code at bytecode.c:1627 is the last line calling alloca_array
>  > below.  I wonder if maybe the compiler doesn't like the local
>  > declaration of struct jump in the middle of the declarations with
>  > initializations, or maybe either the compiler or cygwin.dll just
>  > doesn't handle alloca_array as we expect. 
>
> That’s it--it’s a mundane stack overflow. The length of the instructions
> string is 79648, we try to allocate twice that (= 160k) on the stack,
> Windows refuses. Mule-UCS is horrible code. 
>
> The below makes (require 'un-define) work for me. I’m not sure that it
> doesn’t leak memory in the various error cases, unhappily. 
>
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/bytecode.c,v
retrieving revision 1.14.2.2
diff -u -r1.14.2.2 bytecode.c
--- bytecode.c	2005/01/31 02:55:04	1.14.2.2
+++ bytecode.c	2006/07/31 10:36:05
@@ -1624,7 +1624,7 @@
     int from;
     int to;
   };
-  struct jump * const jumps = alloca_array (struct jump, comfy_size);
+  struct jump * const jumps = xnew_array (struct jump, comfy_size);
   struct jump *jumps_ptr = jumps;
 
   Opbyte *program_ptr = program;
@@ -1868,6 +1868,7 @@
 
   /* *program_ptr++ = 0; */
   *program_length = program_ptr - program;
+  xfree(jumps);
 }
 
 /* Optimize the byte code and store the optimized program, only
>
> -- 
> Santa Maradona, priez pour moi!