ruby-dev

In article <[email protected]>,
  Urabe Shyouhei <[email protected]> writes:

> すると現状ひょっとしてバグってますか?
>
> zsh % ruby -rzlib -e'
>
> Zlib::GzipWriter.open("/dev/null") {|gz|
>    gz.mtime = Time.at(1<<32 - 1)
> }'
> ruby 1.9.2dev (2009-03-11 trunk 22881) [x86_64-linux]
> -e:2:in `mtime=': integer 2147483648 too big to convert to `int' (RangeError)
>         from -e:2:in `block in <main>'
>         from -e:2:in `open'
>         from -e:2:in `<main>'
> zsh: exit 1     ruby -rzlib

これがどうなるべきだという話でしょうか。

RFC 1952 に MTIME は singed か unsigned か書いてない (と思う)
ので、2147483648 に対しどういう挙動が正しいのかはよくわかり
ません。

> むしろtime_tの用法を包含した仕様にすべきで、切り捨てるべきではない、という(そこ
> まで強くは言いませんが)意図でした。time_tを切り捨てない方策としてサブクラス化を
> 提案したつもりです。実現性はともかく。

あぁ、そういう現実的な話であれば、[ruby-dev:38205] に書きま
したが検査するメソッドのほうがサブクラスよりいいんじゃないで
しょうか。

ダウンキャストするかわりにそのメソッドを呼べば同じことができ
るでしょう。

そのメソッドを呼ぶのを忘れたときには、File.utime にたどり着
くまで検出できませんが、その場合に検出するのは難しいんじゃな
いでしょうか。静的型や型推論を導入しない限り。

> それ以外の場合にも興味があります。型がない他の言語では不正な値がどこからやって
> きたかをどのようにデバッグするんでしょう。だれか知りませんかね。

printf デバッグなんじゃないですか。

あぁ、そういえば OCaml のデバッガは逆方向に動かせますね。こ
れは理想的な解決策かもしれません。OCaml が型のない言語だとは
いいませんが。

> BignumとFixnumの例がありますので、time_tよりもさらに小さいクラスがあっても驚き
> ません。

世の中には unsigned な 32 bit time_t を採用した OS もあるよ
うです。(OpenVMS とか OS/2 EMX という話を聞きます。)

冒頭に述べたように、gzip の MTIME は signed か unsigned か不
明ですが、仮に (多くの Unix にあわせて) signed であるとする
と、一方がもう一方の部分集合になっているとは限らないかもしれ
ません。

あと、gzip の MTIME で 0 は 1970-01-01 00:00:00 UTC ではなく、
timestamp が存在しないことを示しているので、この部分も意味が
違うと考えるのが適切かもしれません。

数値の範囲を型で扱おうというチャレンジは新しいものではないと
思いますが、そんなに簡単にいくものでもないような気がします。
少なくとも静的な推論については。

例えば、time + 1000 のクラスはなんでしょう?
1000秒を加えたことにより、time のクラスが表現可能な範囲を外
れてしまうかもしれません。そのときにどのクラスを選ぶんでしょ
う? それとも失敗するんでしょうか?

失敗しない場合、Bignum と Fixnum のように、包含関係であれば
クラスを選ぶのに悩まなくて済むかもしれませんが、32bit
unsigned と 32bit signed とか、そこから 0 を除いた集合、包含
関係とは限らない関係の集合がいくつかあったら、自明とは言いが
たい挙動にならざるを得ないのではないでしょうか。

>> かなりあきらかに Ruby っぽくないというレベルに達していると思
>> います。
>
> そうかなあ。デバッグしやすいプログラムが書けるのは(特にPerlと比べた)Rubyの大き
> な特徴の一つだと思うんだけどなあ。

上記の Ruby っぽくないというのは静的型の導入を指しています。

デバッグしやすいプログラムを書くことにはもちろん賛成です。

そして、もし、time_t の範囲におさまるべきであるとプログラマ
が知っている文脈で、そのことをプログラム上で表現したいとした
ら、その検査をするメソッドを作るというのが適当でしょう。

いままでは暗黙のうちにその検査が行われたと考えられますから、
陽に呼び出さなければならないというのはたしかに手間がかかりま
す。

ですが、File.utime のために使われる Time オブジェクトは割合
としては少なく、大きな問題ではないのではないでしょうか。

また、そういう文脈は本当に安定しているのか、という問題があり
ます。ある時点でそれが正しいとしても、プログラムが変化してい
くうちに変わってしまうかもしれません。

また、utime システムコールが時刻を time_t で受け付けるとして
も、実際のファイルシステムがその範囲をすべて受け付けるかとい
うとそうとは限りません。たとえば、NFS version 3 [RFC 1813]
の struct nfstime3 では uint32 seconds ということですから、
64bit time_t の環境ではうまくいかないかもしれません。試して
ませんけれど。なお、NFS version 4 [RFC 3530] の
struct nfstime4 では int64_t seconds のようです。

そうすると、どうせ確実な検査は File.utime までできないのだか
ら放っておけばいい、という見方もあると思います。
-- 
[田中 哲][たなか あきら][Tanaka Akira]