Invalid character generated with CCL (Re: OpenPGP support ?)
Yoshiki Hayashi
t90553 @ mail.ecc.u-tokyo.ac.jp
1999年 11月 9日 (火) 12:38:11 JST
tomo @ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) writes:
> 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 より小さい値になります。
0x9E と 0x9F は 0xA0 より小さいですね。どうも16進には慣れて
いないようです。(^^;;
> 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 します。
bug を2つ発見しました。まず、CCL_WRITE_CHAR は invalid
sequence 対策がなされていましたが、CCL_WRITE_STRING は無防備
でした。また、Fccl_execute_on_string は make_string をしてい
るので、MULE internal へ変換しているはずなのに、
CCL_MODE_ENCODING で呼ばれていました。
この patch で、上野さんの例と、下の例の場合は core を吐かな
くなることを確認しましたが、これで正しいでしょうか?
これでよければ、後で xemacs-patches に送ります。
# CCL をろくにわかっていない人間が patch を書いているという
# のがおそろしい。(^^;;
(progn
(define-ccl-program tst '(1 (write ?\xa1)))
(ccl-execute-on-string tst (make-vector 9 nil) ""))
Fccl_execute の方はどこでどう使われるのかがまったく想像でき
なかったので、ccl_driver の引数は CCL_MODE_ENCODING のままに
してあります。
-------------- next part --------------
Index: mule-ccl.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/mule-ccl.c,v
retrieving revision 1.13.2.7
diff -u -r1.13.2.7 mule-ccl.c
--- mule-ccl.c 1999/11/04 23:50:13 1.13.2.7
+++ mule-ccl.c 1999/11/09 03:37:11
@@ -688,11 +688,20 @@
ccl->status = CCL_STAT_INVALID_CMD; \
goto ccl_error_handler; \
} \
- else \
- for (i = 0; i < len; i++) \
- Dynarr_add(destination, \
- (XINT (ccl_prog[ic + (i / 3)]) \
- >> ((2 - (i % 3)) * 8)) & 0xFF); \
+ else \
+ { \
+ Bufbyte work[MAX_EMCHAR_LEN]; \
+ for (i = 0; i < len; i++) \
+ { \
+ int ch = (XINT (ccl_prog[ic + (i / 3)]) \
+ >> ((2 - (i % 3)) * 8)) & 0xFF; \
+ int len = ( ch < ( conversion_mode == CCL_MODE_ENCODING ? \
+ 256 : 128 ) ) ? \
+ simple_set_charptr_emchar (work, ch) : \
+ non_ascii_set_charptr_emchar (work, ch); \
+ Dynarr_add_many (destination, work, len); \
+ } \
+ } \
} while (0)
/* Read one byte from the current input buffer into Rth register. */
@@ -1838,7 +1847,7 @@
outbuf = Dynarr_new (unsigned_char);
ccl.last_block = NILP (contin);
produced = ccl_driver (&ccl, XSTRING_DATA (str), outbuf,
- XSTRING_LENGTH (str), (int *)0, CCL_MODE_ENCODING);
+ XSTRING_LENGTH (str), (int *)0, CCL_MODE_DECODING);
for (i = 0; i < 8; i++)
XVECTOR_DATA (status)[i] = make_int(ccl.reg[i]);
XSETINT (XVECTOR_DATA (status)[8], ccl.ic);
-------------- next part --------------
--
Yoshiki Hayashi
More information about the Emacs-mime-ja
mailing list