Re: Dump while making bindist on packages

Matt> This one's the syntax stuff again. I'm pretty sure that all Matt> of these 'VALID_BYTIND_P' crashes (there are at least three Matt> that I know of) are the same error sjt> I got this one, same stack trace as Norbert, I think. sjt> The offending code in my dump seems to be at 4319 of regex.c: sjt> These changes may require fiddling with the new code sjt> (changing array manipulations to pointer idioms, eg) to get sjt> them to make sense. Some more on this. First, the same code occurs in re_search_2 at line 4042. It needs to be fixed there as well. I wonder if re_match_2 is the right place for this adjustment. Shouldn't it be done in re_match_2_internal? (re_search_2 needs to be checked for this issue too.) The proper idiom uses the re_char* variable d (eg, from re_search_2 line 4187): d = ((const unsigned char *) (startpos >= size1 ? string2 - size1 : string1) + startpos); d_size = charcount_to_bytecount (d, 1); range -= d_size; startpos += d_size; I'm not sure if you can use `d' in re_match_2(_internal)? because it seems to be used in a different way from re_search_2. This idiom doesn't seem to appear in re_match_2_internal at all. I suppose this is because there is no issue of "skipping" characters since the re is anchored at point. This idiom recurs often. It probably ought to be encapsulated in a set of macros. (That's not your job unless you volunteer for it---Martin is good at that kind of thing and might be willing to help. Definitely it can't be included in the release.) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."