Invalid character generated with CCL (Re: OpenPGP support ?)

[守岡 知彦 / MORIOKA Tomohiko]

>>>>> [emacs-mime-ja : No.00061] にて
>>>>> “Yoshiki”= Yoshiki Hayashi <t90553 ＠ mail.ecc.u-tokyo.ac.jp> さま曰く:

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 ＠ etl.go.jp>─ ─┬
┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━