In article <[EMAIL PROTECTED]>, "Tim Van Holder" <[EMAIL PROTECTED]> writes: [...] > p->decoding_carryover and p->encoding_carryover are both 0.
> I added some printfs ro read_process_output, in case they're of any help: [...] > ** (coding.c:6365) decode_coding_string() set coding->consumed to 0 > ** (coding.c:6384) decode_coding_string() set coding->consumed to 2374 > + decode_coding_string() on a 1058-byte unibyte string set > coding->consumed to 2374 > + set carryover = nbytes - coding->consumed = 1058 - 2374 = -1316 > So it seems that decode_coding_string() arrives at an overly large > coding->consumed when > adding shrinked_bytes. As decode_coding_string has not been changed for years, it's very surprising that it contains such a bug. Could you try the same operation while setting break point as this? (gdb) br coding.c:6273 (gdb) cond NN to_byte==1058 <- NN is the index number of the break point This stops execution at this line if (require_decoding && coding->type != coding_type_ccl) only when to_byte is 1058 (that should be the case that a bug happens in decode_coding_string). When stopped, please execute the code one line by one by `n' command while checking the values of coding->consumed and shrinked_bytes. --- Kenichi Handa [EMAIL PROTECTED] _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
