Re: Yet another Dynarr leak in redisplay

Nobody completely understands redisplay any more, as Chuck Thompson didn't document it and is no longer available for comment. Ben is (as usual) the best bet. This particular code goes back to prehistory (CVS v1.1). There is a small amount of documentation in the internals manual. The code is pretty nasty stuff, isn't it? add_ichar_rune() can return a Boolean cast to (prop_block_dynarr *), or a "real" (prop_block_dynarr *). add_hscroll_rune() and add_glyph_rune() both return "real" (prop_block_dynarr *)'s. I guess ADD_NEXT_OCTAL_RUNE_CHAR is intended to work around this bogosity, and the final "return NULL" was intended to be "return prop". See also similar code in add_control_char_runes(). I wonder if add_ichar_rune() can be fixed to always return a real (prop_block_dynarr *) or NULL. Jerry's post duplicated in entirety for Ben's benefit. I just sent a patch to xemacs-patches to fix a Dynarr leak in redisplay. Here's another one, but I'm not sure what to do with it. This leak affects both 21.4 and 21.5. In redisplay.c, look at the macro ADD_NEXT_OCTAL_RUNE_CHAR. Note that, if prop is NULL, it is set to a freshly created Dynarr by this macro. The macro is used in the function add_octal_runes, which is just below it. At the end of that function, nothing is done with prop. It is not returned and, more to the point, it is not freed. It looks like the callers of add_octal_runes expected prop to be returned to them. However, I don't understand this code at all, so I'm afraid to touch it. Does anybody know what's going on here? -- Jerry James, Assistant Professor james(a)xemacs.org Computer Science Department http://www.cs.usu.edu/~jerry/ Utah State University -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.