Re: Bug fix to dynamic array reallocation in 21.4.12
No, I don't have an easy test case, though I suspect it would be very
easy to trigger by adding one more DEFVAR_LISP() to the main source
code of 21.4.12; since the dyamic loading of my .ell file triggered it
on its first DEFVAR_LISP(). Things to look for: staticpros has a length
of 1346 elements before the DEFVAR_LISP(), and this additional
staticpro causes it to lengthen. You probably would have hit this in
21.4.13 anyway. (actually now that I think about it some more, there
must be a lot of defvar_lisp() equivalents in all the .el files i load
in my init.el that would contribute to getting this array that high.
hmph.)
Andy
On Thursday, January 30, 2003, at 06:25 PM, Stephen J. Turnbull wrote:
RECOMMEND 21.4
[reply-to set to xemacs-beta]
I still don't have a test case (Andrew, do you?) but as Martin would
say this is "obviously correct". ben?
>>>>> "Andrew" == Andrew Begel <abegel(a)cs.berkeley.edu>
writes:
Andrew> In XEmacs 21.4.12:
Andrew> There is a type mismatch between bytes and # elements in
Andrew> the function dynarr.c:Dynarr_realloc(). [....] Here's a
Andrew> patch that fixes it:
-----------
Andrew Begel
Ph.D. Candidate
Computer Science Division
University of California, Berkeley