[FDclone-users:00909] Re: アーカイブブラウザから戻る位置が時々おかしい

[Takashi SHIRAI <shirai@unixusers.net>]

　しらいです。

In Message-Id <20100714225156.dc03cf4f.riki1017kazu@gmail.com>
        Rikito INAKAZU <riki1017kazu@gmail.com>さんwrites:
> 稲員です。

> > 　汎用性は低いですが、元々 archive browser 用のコードなので、
> > cursor 位置云々に拘る必要はないでしょう。こんな patch で如何
> > でしょうか。
> 
> 
> この patch で正しく動作するようになったのをこちらでも確認しました。

　では、ここいらでそろそろ code freeze して FD-3.00i release
に向けて準備を始めたいと思います。細かな bug fix も含めて結
構修正が溜ってしまったので早めに出したいと思います。


> > 　GNU malloc なんかも segment 違反への耐性が強くて debug に
> > は向いていません。そういう意味では、MINIX のような原始的環境
> > の方が重宝するかも知れませんね。
> 
> 
> 確かに bug の発見だけに限れば素朴な malloc も悪くないかもですね。
> 現代的な malloc が debug 支援機能を持っているにしても普段から on
> じゃないですし。

　メモリ管理は難しい話なんですよ。原因と結果が近接していない
ケースが多いですからね。特に最近の architecture は勝手に GC
を行なわれて予期せぬ挙動に泣くことも多いと思います。
　そもそも OS や library の用意した GC はバグだらけのことが
多いので、そうなるとベンダが patch を release するまで手も足
も出ない訳です。
　逆に C みたいな primitive な環境は、面倒な管理を全部自分で
やらなくてはいけない一方で、何があっても全部自分のせいなので、
自分の力だけで何とか対処出来ます。その方がいいでしょ。

　まぁ今回のような事故を防ぎたければ、例えば
	for (i = 0; argv[i]; i++) free(argv[i]);
みたいなコードは
	for (i = 0; argv[i]; i++) free(argv[i]), argv[i] = NULL;
と NULL で上書きするよう徹底すればいいんですけどね。
　Java や .NET なんかだと、恐いので本当にそういうコード書い
てます。


> まあ要するに色々な環境でテストするのは良いことだって事ですか。

　「色々」と言っても、単に数や種類が多いだけでは意味を成しま
せんよ。特に最近は出来る限り広範囲から集めたつもりでもどれも
POSIX という結果になりがちですから。
　むしろ legacy な環境を一つだけ用意して、そこでのみ動作確認
する方が汎用性が増すかも知れません。後継が先達に倣うことはあ
ってもその逆は難しいですからね。時は巻戻せません。
　そういう意味では BSD4.2 辺りの環境を手元に残しておきたかっ
たんですけどね。

                                               しらい たかし