[ruby-dev:38234] Re: big time

Tanaka Akira さんは書きました:
> In article <[e-mail]>,
>   Urabe Shyouhei <[e-mail]> 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 に対しどういう挙動が正しいのかはよくわかり
> ません。

読む側はunsignedで読んでますけどねえ

zsh % ~/target/trunk/bin/ruby -rstringio -rzlib -ve'

s = open("/tmp/tmp.gz", "r:ASCII-8BIT") {|f| f.read }
s[4,4] = [1<<32 - 1].pack("L")
f = StringIO.new(s)
Zlib::GzipReader.wrap(f) {|gz| p gz.mtime }'
ruby 1.9.2dev (2009-03-31 trunk 23101) [x86_64-linux]
2038-01-19 12:14:08 +0900

>> むしろtime_tの用法を包含した仕様にすべきで、切り捨てるべきではない、という(そこ
>> まで強くは言いませんが)意図でした。time_tを切り捨てない方策としてサブクラス化を
>> 提案したつもりです。実現性はともかく。
> 
> あぁ、そういう現実的な話であれば、[ruby-dev:38205] に書きま
> したが検査するメソッドのほうがサブクラスよりいいんじゃないで
> しょうか。
> 
> ダウンキャストするかわりにそのメソッドを呼べば同じことができ
> るでしょう。
> 
> そのメソッドを呼ぶのを忘れたときには、File.utime にたどり着
> くまで検出できませんが、その場合に検出するのは難しいんじゃな
> いでしょうか。静的型や型推論を導入しない限り。

うーん、もともとの
「ライブラリ作者がいわれのないバグ報告で疲弊するのを避けたい」
というニーズはあまり満たしてくれないのが気になりますが、しょうがないのかなあ。

>> それ以外の場合にも興味があります。型がない他の言語では不正な値がどこからやって
>> きたかをどのようにデバッグするんでしょう。だれか知りませんかね。
> 
> printf デバッグなんじゃないですか。
> 
> あぁ、そういえば OCaml のデバッガは逆方向に動かせますね。こ
> れは理想的な解決策かもしれません。OCaml が型のない言語だとは
> いいませんが。

型というかむしろ逆方向に動かそうとする時にあると困るのは副作用のような気がしま
すが、Ocamlって正格評価だったような、と思ってちょっと調べるとforkするのか。
うーん、これは荒技だな...

>> 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 が存在しないことを示しているので、この部分も意味が
> 違うと考えるのが適切かもしれません。
> 
> 数値の範囲を型で扱おうというチャレンジは新しいものではないと
> 思いますが、そんなに簡単にいくものでもないような気がします。
> 少なくとも静的な推論については。

そういう場合は両方を包含するようなスーパークラスを定義するのだと思います。たと
えばFloatとBignumには共通のNumericというスーパークラスがあります。

> 例えば、time + 1000 のクラスはなんでしょう?
> 1000秒を加えたことにより、time のクラスが表現可能な範囲を外
> れてしまうかもしれません。そのときにどのクラスを選ぶんでしょ
> う? それとも失敗するんでしょうか?
> 
> 失敗しない場合、Bignum と Fixnum のように、包含関係であれば
> クラスを選ぶのに悩まなくて済むかもしれませんが、32bit
> unsigned と 32bit signed とか、そこから 0 を除いた集合、包含
> 関係とは限らない関係の集合がいくつかあったら、自明とは言いが
> たい挙動にならざるを得ないのではないでしょうか。

たとえば3/2のクラスはなんでしょうか? Fixnumですよね。
Rubyの場合は「四則演算では型は変えない方に倒す」という設計なのだと思います。

>>> かなりあきらかに Ruby っぽくないというレベルに達していると思
>>> います。
>> そうかなあ。デバッグしやすいプログラムが書けるのは(特にPerlと比べた)Rubyの大き
>> な特徴の一つだと思うんだけどなあ。
> 
> 上記の Ruby っぽくないというのは静的型の導入を指しています。
> 
> デバッグしやすいプログラムを書くことにはもちろん賛成です。

べつに静的型を導入しなくてもFile.utimeより前に例外を起こす方法はあるじゃないで
すか。つまり現状はそうなわけですけど。

> そして、もし、time_t の範囲におさまるべきであるとプログラマ
> が知っている文脈で、そのことをプログラム上で表現したいとした
> ら、その検査をするメソッドを作るというのが適当でしょう。
> 
> いままでは暗黙のうちにその検査が行われたと考えられますから、
> 陽に呼び出さなければならないというのはたしかに手間がかかりま
> す。
> 
> ですが、File.utime のために使われる Time オブジェクトは割合
> としては少なく、大きな問題ではないのではないでしょうか。

そもそもなんでFile.utimeにはTimeオブジェクトを渡さないといけないんですか?
File.utimeの引数に渡すオブジェクトが、比較したり表示したりするTimeオブジェクト
でないといけない理由はないと思うんですけど。
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 までできないのだか
> ら放っておけばいい、という見方もあると思います。

それはCのうれしくなさがRubyのレベルまで上がってきてるだけで何の解決にもなってな
いように思えます。