アカウント名:
パスワード:
unsignedにするなら2108年?くらいまでモンダイなくなるのに…。データのバイナリ互換性も保たれる。
time_tがエラーに-1を使ってる?そんなのif (t==(time_t)-1)のようにキャストすれば無問題。C言語規格上もこれが正しかったはず。time_tが符号付きとは規定されていなかった。(最新規格は確認してないが当初の規格では)
「年号処理めんどくさいからハードコーディングしたけど、次に年号変わるまでは問題ないからいいよね?」みたいでいやだなぁ
そんな議論は7年前に終わっています
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg444471.html [mail-archive.com]
リンク先を(Google翻訳使って)見てみたが、同じような提案が行なわれているだけであって、「終わっている」==「結論が出ている」≒「32ビットunsignedではダメな理由が説明されてる」ようには見えなかったが?
(John Stultz氏の発言にたいしてコメントはついてないように見えるが…見落としてる?)
実装が終わってんだから議論が終わったかどうかはどうでもいいんじゃないですかね。根本的対応で実装されてんだから、文句言う筋合い皆無だし。
一部のシステムでは1970年以前を表すのに負値を使ってるって聞いたけど。明治末あたりから1970年まで。
聞いたけど何?それこそ規格外でしょ
https://linuxjm.osdn.jp/info/GNU_coreutils/coreutils-ja_207.html [linuxjm.osdn.jp]GNU を始め、POSIX に準拠したほとんどのシステムでは、 POSIX に対する拡張として、こうした時間表記をマイナスの秒数を使うことも含めて、サポートしている。従って、‘@-1’ は 1969-12-31 23:59:59 UTC を表すことになる。
少なくともGNUの実装ではマイナス秒はサポート対象そしてLinuxではそのGNUの実装を使ってるだから修正も面倒だった「聞いたけど何?」って言ってる位だから背景からして理解してないのかな?
あれ。じゃあその「POSIX に対する拡張」を採用したシステムではmaketm()関数とかtime()関数とかどうなってるのかな?これらの関数はエラーの時(time_t)-1を返すと規定されてるはずなのだが。
そうだよ関数(≒システムコール≒カーネル空間側)は定義通りエラーならtime_t型の-1を返すこのtime_t型は実装上中身が符号付正数だったけど、unsigned化で対応して規格外なんか知らんがなんてことは、例えもともと規定されてなくてもカーネルメンテナが許すわけないので論外いわゆる「ユーザ空間をぶっ壊す修正」だもの
一方、各ユーティリティ(ユーザ空間側)は、その関数で帰ってくるtime_t型を実装がそうだったから実質的に32bitの符号付正数と決め打ちして型変換せずに扱ってたり、おまけでマイナス秒に対応したりしてた……ので修正がややこしくなった一因となったのよ
まちがえた。maketmじゃなくてmktimeだった。
加減算とかX秒前を表現するときとか、負数を使えた方が便利だからじゃないの。
規格上、time_tは単なる算術型で符号の有無や整数型かどうかは処理系定義だけど、特定の処理系用コードで4byte符号付き整数型を期待するのは間違っていない。そしてint32_tとtime_tに互換がある前提で書いているコードからしたら、time_tをunsigned にしようが64bitにしようが互換性のない仕様変更なのは変わらない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
なぜ無理やり64ビットにしようとする? (スコア:0)
unsignedにするなら2108年?くらいまでモンダイなくなるのに…。
データのバイナリ互換性も保たれる。
time_tがエラーに-1を使ってる?そんなの
if (t==(time_t)-1)
のようにキャストすれば無問題。C言語規格上もこれが正しかったはず。time_tが符号付きとは規定されていなかった。(最新規格は確認してないが当初の規格では)
Re: (スコア:0)
「年号処理めんどくさいからハードコーディングしたけど、次に年号変わるまでは問題ないからいいよね?」みたいでいやだなぁ
Re: (スコア:0)
そんな議論は7年前に終わっています
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg444471.html [mail-archive.com]
Re: (スコア:0)
リンク先を(Google翻訳使って)見てみたが、同じような提案が行なわれているだけであって、
「終わっている」==「結論が出ている」≒「32ビットunsignedではダメな理由が説明されてる」ようには見えなかったが?
(John Stultz氏の発言にたいしてコメントはついてないように見えるが…見落としてる?)
Re: (スコア:0)
実装が終わってんだから議論が終わったかどうかはどうでもいいんじゃないですかね。
根本的対応で実装されてんだから、文句言う筋合い皆無だし。
Re: (スコア:0)
一部のシステムでは1970年以前を表すのに負値を使ってるって聞いたけど。
明治末あたりから1970年まで。
Re: (スコア:0)
聞いたけど何?それこそ規格外でしょ
Re: (スコア:0)
https://linuxjm.osdn.jp/info/GNU_coreutils/coreutils-ja_207.html [linuxjm.osdn.jp]
GNU を始め、POSIX に準拠したほとんどのシステムでは、 POSIX に対する拡張として、こうした時間表記をマイナスの秒数を使うことも含めて、サポートしている。
従って、‘@-1’ は 1969-12-31 23:59:59 UTC を表すことになる。
少なくともGNUの実装ではマイナス秒はサポート対象
そしてLinuxではそのGNUの実装を使ってる
だから修正も面倒だった
「聞いたけど何?」って言ってる位だから背景からして理解してないのかな?
Re: (スコア:0)
あれ。じゃあその「POSIX に対する拡張」を採用したシステムではmaketm()関数とかtime()関数とかどうなってるのかな?これらの関数はエラーの時(time_t)-1を返すと規定されてるはずなのだが。
Re:なぜ無理やり64ビットにしようとする? (スコア:1)
そうだよ
関数(≒システムコール≒カーネル空間側)は定義通りエラーならtime_t型の-1を返す
このtime_t型は実装上中身が符号付正数だったけど、unsigned化で対応して規格外なんか知らんがなんてことは、例えもともと規定されてなくてもカーネルメンテナが許すわけないので論外
いわゆる「ユーザ空間をぶっ壊す修正」だもの
一方、各ユーティリティ(ユーザ空間側)は、その関数で帰ってくるtime_t型を実装がそうだったから実質的に32bitの符号付正数と決め打ちして型変換せずに扱ってたり、おまけでマイナス秒に対応したりしてた……ので修正がややこしくなった一因となったのよ
Re: (スコア:0)
まちがえた。maketmじゃなくてmktimeだった。
Re: (スコア:0)
加減算とかX秒前を表現するときとか、負数を使えた方が便利だからじゃないの。
規格上、time_tは単なる算術型で符号の有無や整数型かどうかは処理系定義だけど、特定の処理系用コードで4byte符号付き整数型を期待するのは間違っていない。
そしてint32_tとtime_tに互換がある前提で書いているコードからしたら、time_tをunsigned にしようが64bitにしようが互換性のない仕様変更なのは変わらない。