[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[FDclone-users:00836] Re: FreeBSD/ports for 7.0R
- Subject: [FDclone-users:00836] Re: FreeBSD/ports for 7.0R
- From: Takashi SHIRAI <shirai@unixusers.net>
- Date: Sun, 16 Nov 2008 01:08:14 +0900
しらいです。
In Message-Id <491ECEE6.2080707@imao.jp>
Yasushi Imao <yasushi_imao@imao.jp>さんwrites:
> お世話になります。今尾です。
> tcsh でログインして、fdsh を起動した状態でも実験していましたが、まったく
> 同様です。
となると login shell がどうのというのは関係ありませんね。
他の shell で login してから fd を起動して EXECUTE_SH の中で
補完を行なっても再現するんじゃないでしょうか。
> 私も FreeBSD と Linux (Ubuntu 8.04、CentOS 5) で試して、FreeBSD でのみ再
> 現しましたので、FreeBSD の最近のバージョン固有と思っていましたが、
> Solaris 10 X86 でも login shell として利用する、fdsh を他の shell からっ
> 起動するの両方の方法で再現できました。Solaris 環境で日本語を使う機会があ
> りませんでしたので気がつきませんでした。
Solaris10 は持ってるので確認してみましたが、またもや再現し
ませんでした。
$ uname -a
SunOS solaris10 5.10 Generic_118844-08 i86pc i386 i86pc
$ pwd
/home/fdclone/utf8/テスト
$ cat ~/.fdshrc
if [ -f ~/.fd2rc ]; then
. ~/.fd2rc
fi
$ cat ~/.fd2rc
FNAMEKCODE=utf8
$ dir
Directory of /home/fdclone/utf8/テスト
. <DIR> 08-11-15 23:35 .
.. <DIR> 08-11-15 23:35 ..
111 TXT 0 08-11-15 23:35 111.txt
111 <DIR> 08-11-15 23:35 111
1日本語 <DIR> 08-11-15 23:35 1日本語
1 file(s) 0 bytes
4 dir(s) 206,387,200 bytes free
$ echo 1 (←ここで Tab)
111 111.txt 1日本語
$ echo 1
> EUC で作成した "テスト" に対して LANG=ja_JP.EUC 環境下で "ln -s テスト
> test" を実行し、UTF-8 では cd test で行いました。pwd で current
> directory をみると /home/yimao/tmp/test になったので、再現させるのは無理
> かと思いましたが、この状態でも再現 (FNAMAKCODE="utf8" で freeze) できま
> した。
ふむ、こっちのケースは Solaris10 で再現しました。
色々試してみたところ、下記のような対処で再現しなくなったん
ですが、そちらの環境ではどうでしょう？もしかすると UTF-8 な
directory の件も再現しなくなりませんか？
---- Cut Here ----
diff -u ../old/FD-3.00c/sysemu.c ./sysemu.c
--- ../old/FD-3.00c/sysemu.c Sun Jul 27 00:00:00 2008
+++ ./sysemu.c Sun Nov 16 00:50:21 2008
@@ -493,7 +493,7 @@
CONST char *path;
{
# if defined (DEP_KANJIPATH) || defined (DEP_ROCKRIDGE)
- char conv[MAXPATHLEN];
+ char *cp, conv[MAXPATHLEN];
# endif
int n;
@@ -519,8 +519,8 @@
case OP_DIRP:
body_dirp(n) = (DIR *)bodyp;
# if defined (DEP_KANJIPATH) || defined (DEP_ROCKRIDGE)
- openlist[n].path =
- strdup2(convput(conv, path, 0, 1, NULL, NULL));
+ cp = convput(conv, path, 0, 1, NULL, NULL);
+ openlist[n].path = strdup2(cp);
# endif
break;
case OP_FD:
@@ -1036,7 +1036,7 @@
return(pseudoreaddir(dirp));
#else /* DEP_DOSEMU || DEP_URLPATH || DEP_KANJIPATH || DEP_ROCKRIDGE */
# if defined (DEP_KANJIPATH) || defined (DEP_ROCKRIDGE)
- char path[MAXPATHLEN], conv[MAXPATHLEN];
+ char *cp, path[MAXPATHLEN], conv[MAXPATHLEN];
# endif
static st_dirent buf;
struct dirent *dp;
@@ -1086,7 +1086,8 @@
# if defined (DEP_KANJIPATH) || defined (DEP_ROCKRIDGE)
if (n >= 0) {
strcatdelim2(path, openlist[n].path, src);
- if (convget(conv, path, dev) == conv) {
+ cp = convget(conv, path, dev);
+ if (cp == conv) {
if ((src = strrdelim(conv, 0))) src++;
else src = conv;
}
---- Cut Here ----
変更点を見て貰うと判ると思いますが、もしこの patch で直る
としたら、多分それは compiler の最適化 bug ですよ。関数の返
り値を意味もなく一旦変数に格納しただけですから。
変数に格納しないでそのまま引数にして渡した場合、何故かポイ
ンタ値が NULL になっていました。返り値は NULL じゃないのにど
こかでいつの間にかすり変わってますね。
debugger で細かく追うと判るとは思いますが、buffer overflow
でもなきゃ明らかな bug です。結構執拗に追ってみたんですけど、
buffer overflow は生じてなさそうなんですよね。
もしこれが原因なら特定の OS に依存するという現象にも説明が
つきますね。FreeBSD も Solaris も gcc を使っているかと思いま
すが、環境によって version がまちまちですから。
因みにうちの Solaris の gcc はこんなのでした。
$ gcc --version
gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 日本語 directory 配下の tab 補完は結構頻繁に使う機会があると思うんです
> が、私のところだけで再現するところをみると、どうやら私個人の設定/使用方
> 法に問題にあるような気がしてきました。実はこの問題は以前から発生していた
> んですが、再現条件が特定できていませんでしたので、他の方から報告があるの
> を期待して待っていました。ですが、一向にその気配がありませんでしたので、
> 今回思い切ってご相談させていただきました。が、結局お騒がせしただけに終わ
> りそうで少し残念です。
もし compiler のせいだとすると個人の問題に近いところがある
とは思いますが、影響範囲は一個人よりはまだ広いので、対応可能
な限りは対応したいと思っています。
結論はまだ出ていませんが、私も最後まで諦めずに対応していく
つもりですので、ご面倒でも気長におつき合い下さい。
しらい たかし