-
kosaki55tea
- 5086
- 2
- 1
- 0
-
- いいね！0
Jitsumoto Hideyuki
@RyzeVia
struct timespec {tv_sec, tv_nsec} で tv_sec 側は、time_t なんだが、こいつの型が不明なせいで、sscanf で受けられない。でもどうせintでいいやと高をくくって%dで受けたのが間違い。int で受けてから代入しないとだめなようだ。
2013-03-22 17:32:03
Jitsumoto Hideyuki
@RyzeVia
もうほんと・・・time_t 勘弁してください・・・。time_t a = (time_t) i; とかちゃんとキャストできるのかも不定じゃないの？
2013-03-22 17:37:12
Jitsumoto Hideyuki
@RyzeVia
敗因はやっぱりprintf/sscanf だなぁ。両方とも %d で受けりゃ、そりゃあ正しいデータがでるよ。上位ビット無視しちゃうんだから。
2013-03-22 17:40:51
Jitsumoto Hideyuki
@RyzeVia
おおそうか ANSI-C で time_t は整数値ということは決まってるんだから、十分大きい整数型へのキャストは成功するわけだ。とはいえ、それだとまたXXXX年問題起こるんだろうが。（起こらないために作ったtime_t を改悪する魔の所行）
2013-03-22 17:47:36
Tanaka Akira
@tanaka_akr
gcc は 4.6 から __int128 をサポートしているのか。しかし intmax_t は依然として 64bit だな。まぁコンパイラがサポートした整数型が増えたからといって intmax_t を変えると ABI が壊れちゃうよなぁ。
2013-03-24 03:10:46
成瀬
@nalsh
@neriring2 典型的にはintmax_t=64bitな状態でアプリをインストールした後、OSアップデートしてccやライブラリがintmax_t=128になったら、アプリが死ぬって話になると思う
2013-03-24 04:05:00
小崎 資広 (KOSAKI Motohiro)
@kosaki55tea
intmax_tはlibcがサポートする最大サイズで典型的にはprintfがサポートするサイズを取得できることに意味があるので gccが int128を実装しても glibcがガン無視はそう不自然でもない
2013-03-24 04:22:36
小崎 資広 (KOSAKI Motohiro)
@kosaki55tea
@nalsh なるほど。glibcはABI互換にこだわってるので、当面bump予定はないですね
2013-03-24 04:25:02
Tanaka Akira
@tanaka_akr
System V Application Binary Interface AMD64 Architecture Processor Supplement (Draft Version 0.95) には intmax_t は定義されてないのだな。
2013-03-24 04:42:57
Tanaka Akira
@tanaka_akr
む、Linux Standard Base Core Specification for AMD64 3.1 には typedef long int intmax_t という定義がある感じ?
2013-03-24 04:45:34
Tanaka Akira
@tanaka_akr
Linux Standard Base は ISO/IEC 23360 で、そこで intmax_t が決まっているということは、いつか規格もどうにかすることになるのかな。
2013-03-24 05:05:52
Tanaka Akira
@tanaka_akr
@kosaki55tea まぁどうしても変えざるを得ないタイミングでないとねぇ。IA32 なら 2038年問題で機会があるのかな。(それとも x32 に移ってしまうのだろうか。)
2013-03-24 11:19:56
小崎 資広 (KOSAKI Motohiro)
@kosaki55tea
@tanaka_akr 2038年問題でABIを変えるならx32でいいじゃんという話にしかならなさそう
2013-03-24 11:20:57