Yoshiki> 追っかけてみましたが、引数 source は NULL で呼ばれていますし、 Yoshiki> CCL 自体の吐き出す結果は正しいです。(Emacs 20.4 の結果が正し Yoshiki> いと仮定した場合。) やはり。 だから終了処理に行かず誤動作した挙げ句 invalid sequence を作って crash するんですね。 Yoshiki> そして、XEmacs の挙動も beta 版としては正しいと思います。 Yoshiki> abort しているのは、buffer.h の VALID_CHAR_PTR_P ですが、 Yoshiki> それの実体は BUFBYTE_FIRST_BYTE_P で、 Yoshiki> #define BUFBYTE_FIRST_BYTE_P(c) ((c) < 0xA0) Yoshiki> という定義になっているからです。0xa1 というのは MULE の Yoshiki> internal code では存在しないはずの値ですから。 Yoshiki> ところで、この check だと private charset は考慮していないと Yoshiki> 思うのですが、それは正しいのでしょうか? 正しいです。 leading-byte 表現では、official-charset の charset-id はそのまま leading-byte (multibyte 文字表現の第 1 byte) になりますが、 private-charset の charset-id は leading-byte にならず、private 用の prefix leading-byte が用いられます。よって、必ず multibyte 文字表現の 第 1 byte は 0xA0 より小さい値になります。 Yoshiki> ついでに、ccl_driver は引数 source を NULL と仮定した code Yoshiki> になっていますが、GNU Emacs の code は NULL でなくても動作す Yoshiki> るようになっています。今の所は大丈夫ですが、GNU Emacs が拡張 Yoshiki> されて sync するときに、また問題が起こりそうな気がするのです Yoshiki> が、大丈夫なのでしょうか? 良く判りません。 ;; 仮にまた Emacs の CCL が拡張されてももう私は sync しないので大丈夫 ;; です。:-) Yoshiki> で、本当の問題は、CCL が吐き出す invalid sequence は Yoshiki> make_string に渡されるまで、全く check されていないというこ Yoshiki> となのですが、何故なのでしょう? XEmacs-Mule では invalid sequence を check する代わりに invalid sequence が生じないようにします。CCL の場合、ccl_driver の引数 conversion_mode が CCL_MODE_DECODING であれば CCL_WRITE_CHAR が 0x80 以上の値をその値に対応する文字を表す列に encode します。 Yoshiki> # ようやく少しだけ MULE の内部構造が分かったような気がします。 Yoshiki> # 私の環境では致命的な crash を引き起こす MULE 関連の bug を Yoshiki> # ようやく潰せましたし。(^^;; Yoshiki> # 環境によっては、remote exploit 可能です。:-P ;; ぱちぱち。 ;;; これで安心して引退できる!? -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <tomo(a)etl.go.xn--jp&gt;-8n7c ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━