From: nobu.nakada@...
Date: 2003-12-05T20:46:37+09:00
Subject: [ruby-dev:22160] Re: Dir.glob   	と  Shjift_JIS   について

なかだです。

At Fri, 5 Dec 2003 20:21:38 +0900,
H.Yamamoto wrote:
> >見直してもいいんじゃないかと思いますが、具体的にはどういう構造
> >を考えてますか?
> 
> 今頭にあるのは、fnmatch を glob に合わせて、
> 
> * ? [ ] { } **/ '\0'区切り
> 
> を使えるようにして、パス区切りは / に統一して、\ はエスケープ専用にする。
> （'\?' は '?' にマッチ：? は任意の１文字）
> FNM_CASEFOLD は そのまま
> FNM_PATHNAME は **/ があるので廃止
> FNM_NOESCAPE は '\' がほしいときは '\\' とすることにして廃止
> FNM_DOTMATCH は よくわかりません。

fnmatchでも**を扱えるようにするというのはいいかもしれませんが、
FNM_PATHNAMEって意味は逆じゃありませんでしたっけ。

> FNM_CASEFOLD は、環境によってデフォルトを変えてもいいかもしれません。
> Win32ではON、UNIXではOFFという具合に。

Win32というよりはDOSISHでしょうね。

> >> これから最適化に入ります。nobuさんに指摘された、*p == '\0'の場合
> >> 単に ++p でいいんじゃないかというのは、最適化の最終でやるつもりです。
> >
> >これは最適化というよりも、むしろ無用にNext()が複雑化しているの
> >が、使ってはいけないところにまで使おうとしているせいなんじゃな
> >いかと思うのですが。
> 
> 無用にというのは、greater((p) + 1, (p) + mblen(p, INT_MAX)) の部分でしょうか？
> mblenはエラーのとき（マルチバイト文字が不完全だったとき？）-1 を返すそうなのですが、
> それは起こらないとしていい？

あー、それはどうすべきでしょうねぇ。基本的にutil.cのmblen()しか
想定してないはずなので。例外にするべきか、単独バイトとして扱う
ほうがいいのか。

> 個人的には、シングルバイト文字に Next() を呼ぶオーバーヘッドよりも、

全然オーバーヘッドを気にしているわけではなくて、ターミネータを
越えてアクセスしようとするところが、バッファオーバーランを誘発
しそうでなんとなく気になってます。

> aa/aa/aa/aa/* みたいに、最後が magic なパターンで glob_helper を呼んだ場合に、 / の度に
> 
>     p = sub ? sub : path;
>     if (!has_magic(p, 0, flags)) {
> #if defined DOSISH
> 	remove_backslashes(path);
> #else
> 	if (!(flags & FNM_NOESCAPE)) remove_backslashes(p);
> #endif
> 
> が呼ばれる部分の方がマルチバイト環境では気になります。

これはまぁ、以前から若干思わないでもなかったのですが、トータル
としてはそう大きくはならないだろうと思ってます。

> 特に、extract_path をマルチバイト対応にするときかなり遅い実装にしてしまったので、
> これをなんとかしたいです。

それは個別に改善を図るということで。

-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦