[ruby-dev:22158] Re: Dir.glob と Shjift_JIS について

山本です。

>見直してもいいんじゃないかと思いますが、具体的にはどういう構造
>を考えてますか?

今頭にあるのは、fnmatch を glob に合わせて、

* ? [ ] { } **/ '\0'区切り

を使えるようにして、パス区切りは / に統一して、\ はエスケープ専用にする。
（'\?' は '?' にマッチ：? は任意の１文字）
FNM_CASEFOLD は そのまま
FNM_PATHNAME は **/ があるので廃止
FNM_NOESCAPE は '\' がほしいときは '\\' とすることにして廃止
FNM_DOTMATCH は よくわかりません。

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

>> これから最適化に入ります。nobuさんに指摘された、*p == '\0'の場合
>> 単に ++p でいいんじゃないかというのは、最適化の最終でやるつもりです。
>
>これは最適化というよりも、むしろ無用にNext()が複雑化しているの
>が、使ってはいけないところにまで使おうとしているせいなんじゃな
>いかと思うのですが。

無用にというのは、greater((p) + 1, (p) + mblen(p, INT_MAX)) の部分でしょうか？
mblenはエラーのとき（マルチバイト文字が不完全だったとき？）-1 を返すそうなのですが、
それは起こらないとしていい？

個人的には、シングルバイト文字に 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 をマルチバイト対応にするときかなり遅い実装にしてしまったので、
これをなんとかしたいです。