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