TStcltk 発言

ビットウォークの高橋です。

>私と「ほぼ」同じ修正内容ですね。
>違うのは、channelからISO2022-JPをdecodeするときの
>変換する長さを約30文字から約20文字に減らしている点です。
>(ENCODING_LINESIZEを30→20に変更している)
>これの理由はよく解りません。要らないはずですけど...
>現象を確認するために減らしたのかな?
>

http://sourceforge.net/tracker/index.php?func=detail&aid=523988&group_id=10894&atid=110894

の記述に、

Jeff Hobbs posted: "OK, on this one Thomas keyed me in by pointing out
that only his strict example fails (using gets - read is OK). So I honed
in on that, and was further keyed in that he noted only X chars ever get
translated. Poking around, I found the problem in
tclIO.c:FilterInputBytes. It has something to do with the value of the
ENCODING_LINESIZE #define (currently 30). If I bump that up to 60, I can
read Thomas' sample just fine, and if I drop it to 20, it stops the
correct encoding translation even earlier per line. That's obviously not
a correct fix, but it does indicate that FilterInputBytes isn't encoding
right. I'll have to look into this more when it's not past midnight ..."

とあるように、いろいろテストしているようですね。

>
># って、よく見てみると523988.patchってMarch 1に修正!?
># なんとまあ、タイミングが良いというか悪いというか。
>

そうです。まさにホットな話題だったのです（正確には2月末の話題です）。
Jeff氏はTcl Core Team(TCT)の中でTcl/Tkのバージョンリリースを決断できる立
場なので、ソースへパッチを取り込むプロセスも短いのです。
この件に関する担当はJan Nijtman氏のはずなので、なんか不公平な気がします
が、異国の人間が集まってTCTを組織し開発している以上、誰かが決定権を行使
できるのは、致し方ないことですし、却って都合が良い場合もあります。

Jeff氏によれば、8.4の正式リリースまでにはこの手の問題をしっかり解決した
いということですので、この機に乗ずればこちらの改善要求もすんなり通るよう
な気がします。 :-)

-- 
Keiichi Takahashi, bitWalk Co.,Ltd.
mailto:bitwalk@...
http://members10.tsukaeru.net/bitwalk/