From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: process output has become a bit random... Date: Mon, 2 Aug 2004 09:03:08 +0900 (JST) Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <200408020003.JAA21336@etlken.m17n.org> References: <4108D78A.7090001@math.ku.dk> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1091405060 5075 80.91.224.253 (2 Aug 2004 00:04:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 2 Aug 2004 00:04:20 +0000 (UTC) Cc: emacs-devel@gnu.org, storm@cua.dk Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 02 02:04:08 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BrQJE-0003xu-00 for ; Mon, 02 Aug 2004 02:04:08 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BrQMa-0007DX-GJ for ged-emacs-devel@m.gmane.org; Sun, 01 Aug 2004 20:07:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BrQMU-0007DO-Uy for emacs-devel@gnu.org; Sun, 01 Aug 2004 20:07:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BrQMT-0007Cx-1y for emacs-devel@gnu.org; Sun, 01 Aug 2004 20:07:30 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BrQMS-0007Cu-VT for emacs-devel@gnu.org; Sun, 01 Aug 2004 20:07:29 -0400 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BrQIZ-0004fk-43; Sun, 01 Aug 2004 20:03:27 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id i72039xK018965; Mon, 2 Aug 2004 09:03:09 +0900 Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.6p2/8.11.6) with ESMTP id i72038U21251; Mon, 2 Aug 2004 09:03:08 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id JAA21336; Mon, 2 Aug 2004 09:03:08 +0900 (JST) Original-To: dak@gnu.org In-reply-to: (message from David Kastrup on 01 Aug 2004 02:28:38 +0200) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:26147 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:26147 In article , David Kastrup writes: > [2 ] > --- coding.c 22 Jun 2004 11:22:11 +0200 1.305 > +++ coding.c 01 Aug 2004 02:17:32 +0200 > @@ -5330,7 +5330,7 @@ > /* As shrinking conversion region requires some overhead, we don't try > shrinking if the length of conversion region is less than this > value. */ > -static int shrink_conversion_region_threshhold = 1024; > +static int shrink_conversion_region_threshhold = 4100; > #define SHRINK_CONVERSION_REGION(beg, end, coding, str, encodep) \ > do { \ > [3 ] > This might explain why the changes in buffer size that I did > previously triggered problems: that way the buffer could get larger > than this threshold of 1024 bytes. It would appear that as soon as > shrink_decoding_region is called via SHRINK_CONVERSION_REGION in > decode-coding-string, things start going haywire. Thank you for tracking the problem down to here. I'll check what's wrong with shrink_conversion_region soon. --- Ken'ichi HANDA handa@m17n.org