[#25976] tnono dumps core — nobu@...

なかだです。

16 messages 2005/04/02
[#25977] Re: tnono dumps core — Masaki Suketa <masaki.suketa@...> 2005/04/03

助田です。

[#25998] ruby 1.8.3 preview予定 — Yukihiro Matsumoto <matz@...>

まつもと ゆきひろです

45 messages 2005/04/07
[#26011] bcc32、win32 での install-doc の動作 — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/04/10

山本です。

[#26012] Re: bcc32、win32 での install-doc の動作 — nobu@... 2005/04/10

なかだです。

[#26013] Re: bcc32、win32 での install-doc の動作 — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/04/11

山本です。

[#26014] Re: bcc32、win32 での install-doc の動作 — "U.Nakamura" <usa@...> 2005/04/11

こんにちは、なかむら(う)です。

[#26034] Re: bcc32、win32 での install-doc の動作 — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/04/12

山本です。

[#26035] Re: bcc32、win32 での install-doc の動作 — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/04/12

山本です。

[#26036] Re: bcc32、win32 での install-doc の動作 — "U.Nakamura" <usa@...> 2005/04/12

こんにちは、なかむら(う)です。

[#26040] Re: bcc32、win32 での install-doc の動作 — nobu@... 2005/04/13

なかだです。

[#26041] Re: bcc32、win32 での install-doc の動作 — "U.Nakamura" <usa@...> 2005/04/13

こんにちは、なかむら(う)です。

[#26042] Re: bcc32、win32 での install-doc の動作 — nobu@... 2005/04/13

なかだです。

[#26043] Re: bcc32、win32 での install-doc の動作 — "U.Nakamura" <usa@...> 2005/04/13

こんにちは、なかむら(う)です。

[#26045] Re: bcc32、win32 での install-doc の動作 — nobu@... 2005/04/13

なかだです。

[#26049] Re: bcc32、win32 での install-doc の動作 — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/04/14

山本です。

[#26051] Re: bcc32、win32 での install-doc の動作 — nobu@... 2005/04/14

なかだです。

[#26059] Re: bcc32、win32 での install-doc の動作 — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/04/14

山本です。

[#26060] Re: bcc32、win32 での install-doc の動作 — nobu@... 2005/04/15

なかだです。

[#26100] FileUtils.rm_rf security problem — Tanaka Akira <akr@...17n.org>

ふと、CVE で perl 関係のを見ていたら、File::Path の rmtree に関するも

21 messages 2005/04/26
[#26102] Re: FileUtils.rm_rf security problem — Tanaka Akira <akr@...17n.org> 2005/04/26

[#26190] Re: FileUtils.rm_rf security problem — Minero Aoki <aamine@...> 2005/05/20

青木です。

[#26191] Re: FileUtils.rm_rf security problem — Tanaka Akira <akr@...17n.org> 2005/05/20

In article <20050520171837N.aamine@loveruby.net>,

[#26192] Re: FileUtils.rm_rf security problem — Minero Aoki <aamine@...> 2005/05/20

青木です。

[#26197] Re: FileUtils.rm_rf security problem — Minero Aoki <aamine@...> 2005/05/21

青木です。

[ruby-dev:25996] Re: some trouble on ext/tk/sample

From: "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
Date: 2005-04-06 14:02:43 UTC
List: ruby-dev #25996
山本です。

>というわけで,configinfo または current_configinfo を
>使っても良かったのですが,Tcl/Tk が返してくる文字列情報を
>Ruby/Tk 内部で変換して,さらにその Array または Hash で
>検索をかけねばならないのであれば,直接に問題のオプションを参照して
>エラーを捕まえた方が手っ取り早いかなと考えた次第です.

なるほど。

>判断誤りの心配がなくそれだけ早くなるなら有効な対策かもしれませんね.

すみません、このパッチは試しに作ったいい加減なパッチで、
例えば ascii 互換でないエンコーディングが存在して、
tcl がそれをサポートしていて、そういった文字が渡ってきた場合は
考慮していませんでした。それ以外でもちゃんと動くか怪しいです。

Index: tcltklib.c
===================================================================
RCS file: /src/ruby/ext/tk/tcltklib.c,v
retrieving revision 1.10
diff -u -w -b -p -r1.10 tcltklib.c
--- tcltklib.c	30 Mar 2005 08:44:15 -0000	1.10
+++ tcltklib.c	4 Apr 2005 10:49:42 -0000
@@ -5961,6 +5961,24 @@ ip_restart(self)
     return lib_restart(self);
 }
 
+static int
+is_ascii(const char* p)
+{
+/*
+    for (; *p; p++)
+	if (!isprint(*p))
+	    return 0;
+
+    return 1;
+*/
+
+    for (; *p; p++)
+	if (!(0x21 <= *p && *p <= 0x7E))
+	    return 0;
+
+    return 1;
+}
+
 static VALUE
 lib_toUTF8_core(ip_obj, src, encodename)
     VALUE ip_obj;
@@ -5982,6 +6000,9 @@ lib_toUTF8_core(ip_obj, src, encodename)
     if (NIL_P(src)) {
       return rb_str_new2("");
     }
+    if (is_ascii(RSTRING(src)->ptr)) {
+	return src;
+    }
 
 #ifdef TCL_UTF_MAX
     if (NIL_P(ip_obj)) {
@@ -6134,6 +6155,9 @@ lib_fromUTF8_core(ip_obj, src, encodenam
 
     if (NIL_P(src)) {
       return rb_str_new2("");
+    }
+    if (is_ascii(RSTRING(src)->ptr)) {
+	return src;
     }
 
 #ifdef TCL_UTF_MAX

/////////////////////////////////////////////////////////////////

>現在の tktreectrl.rb では全般に tk_call や tk_send を呼んでおり,
>スピード面でのチューニングは施していません.
>tk_call または tk_send は Tk サイドを手っ取り早く呼べるんですが,
>明らかに変換の必要がないケースでも変換処理を行ってしまいます.
>その点がかなりの無駄になっています.
>ですので,tk_call_without_enc や tk_send_without_enc と,
>_get_eval_string(val, true) とを組み合わせて,
>変換処理を行う引数を絞ってやるだけで,
>かなりのスピードアップになるはずです.

うわー、手動でやらないといけないんですね・・・何とか自動化できないか
しばらく考えたんですが、「ascii 非互換なエンコーディングは ID_at_enc を
指定した文字列という形でしか使えない」という感じにしないと無理そうで・・・
無理なのかなあ。


In This Thread