2023 年, 操作系统的 time_t 类型 就溢出了, 目前有对此做什么么?

[DinoStray]

[mcoo1997]

尽量不要过到 2023 年

[pursuer]

是 2038 年 1 月吧

[ho121]

大部分系统应该切换到 64 位了吧

[DinoStray]

@pursuer 对, 我打错了

[whenov]

使用 time_t 的话已经与具体实现解耦了，只要及时更新操作系统和编译器应该不会有大问题

[Jirajine]

到那个时候估计现在的主流操作系统都更新换代了。

[elfive]

基本上除了少数用到了类似于 printf 函数（主要是%d,%ld 这些），以及一些强制转字节流等操作的以外（可能涉及到序列化存取），几乎都只需要重新用 64 位编译器编译一下就能解决……

[mepwang]

@ho121 切 64 位不影响已有系统吧，并且一般 64 位 c 语言只有 long long 整数和指针，还有明确指定是 64 位的数据类型，是 64 位的

[BrettD]

@ho121 问题在于虽然系统是 64 位，为了兼容旧程序，time_t 还是 32 位整数

[ho121]

@BrettD 记得 64 位编译出来的 sizeof time_t 是 8

[wty]

c 库已经换成 64 位了，写 time_t 默认 64 位。time 函数什么的都会被重新定义到 64 位版本上去。新编译的程序应该大多没啥问题

[learningman]

time_t 本来就是个宏，重新指定到 int_64 呗

[nightwitch]

https://code.woboq.org/userspace/glibc/posix/bits/types.h.html#_M/__SQUAD_TYPE
glibc 的 time_t 已经换成 64 位很久了

[systemcall]

得看谭浩强和廖雪峰打不打算拯救众生

[BrettD]

@ho121 哦好吧我记忆过时了，我记得几年前看到帖子说为了维持 ABI 兼容性导致 time_t 仍然 32 位。

[alazysun]

那时候 32 位也应该取缔了把

[fiveelementgid]

32 位已经退役了吧

[jzmws]

这个和 MySQL timestamp 是一样的把?

[laucenmi]

还有好多设备是 32 位的...

[shuax]

typedef __time64_t time_t;