tomo(a)etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) writes:
>>>>> In [emacs-mime-ja : No.00031]
>>>>> "Daiki" = Daiki Ueno <ueno(a)ueda.info.waseda.ac.jp>
wrote:
Daiki> ;; 関係ないですが、XEmacs で以下の式を評価すると.....
Daiki> ;; (progn
Daiki> ;; (require 'pccl)
Daiki> ;; (define-ccl-program tst '(1 ("\xa1")))
Daiki> ;; (ccl-execute-on-string tst (make-vector 9 nil) ""))
とりあえず少しだけ追っかけてみた所、なんとなく、入力が空文字列だった時
に ccl_driver の引数 source が NULL であることが仮定されているのにも関
わらず、そうなっていないために不具合が起こっているような気がしました。
追っかけてみましたが、引数 source は NULL で呼ばれていますし、
CCL 自体の吐き出す結果は正しいです。(Emacs 20.4 の結果が正し
いと仮定した場合。)
そして、XEmacs の挙動も beta 版としては正しいと思います。
abort しているのは、buffer.h の VALID_CHAR_PTR_P ですが、
それの実体は BUFBYTE_FIRST_BYTE_P で、
#define BUFBYTE_FIRST_BYTE_P(c) ((c) < 0xA0)
という定義になっているからです。0xa1 というのは MULE の
internal code では存在しないはずの値ですから。
ところで、この check だと private charset は考慮していないと
思うのですが、それは正しいのでしょうか?
ついでに、ccl_driver は引数 source を NULL と仮定した code
になっていますが、GNU Emacs の code は NULL でなくても動作す
るようになっています。今の所は大丈夫ですが、GNU Emacs が拡張
されて sync するときに、また問題が起こりそうな気がするのです
が、大丈夫なのでしょうか?
で、本当の問題は、CCL が吐き出す invalid sequence は
make_string に渡されるまで、全く check されていないというこ
となのですが、何故なのでしょう?
# ようやく少しだけ MULE の内部構造が分かったような気がします。
# 私の環境では致命的な crash を引き起こす MULE 関連の bug を
# ようやく潰せましたし。(^^;;
# 環境によっては、remote exploit 可能です。:-P
--
Yoshiki Hayashi