当前位置: 技术问答>linux和unix
time_t 的大小的问题
来源: 互联网 发布时间:2016-02-19
本文导语: 大家都知道time_t存的是1970年1月1日0时0分0 秒算起至今的UTC时间所经过的秒数, time_t是long int类型,在我的机器上用sizeof查看,发现是占4字节,signed型的4字节正数最大为2147483647(21亿); 而现在已经快12亿了,我想请问...
大家都知道time_t存的是1970年1月1日0时0分0 秒算起至今的UTC时间所经过的秒数,
time_t是long int类型,在我的机器上用sizeof查看,发现是占4字节,signed型的4字节正数最大为2147483647(21亿);
而现在已经快12亿了,我想请问在2038年之后的某一天会不会出问题?
还有想问一下在UNIX平台下,long型长度是不是跟机器有关,32位机器就是4字节,64位机器就是8字节?
time_t是long int类型,在我的机器上用sizeof查看,发现是占4字节,signed型的4字节正数最大为2147483647(21亿);
而现在已经快12亿了,我想请问在2038年之后的某一天会不会出问题?
还有想问一下在UNIX平台下,long型长度是不是跟机器有关,32位机器就是4字节,64位机器就是8字节?
|
相信在2038年,time_t已经是64位的了。
int大小跟编译器有关,在32位CPU上用TC2.0,int还是2字节,int == short int。
long的长度是C规定的,就是4字节,不管在什么编译器上都一样。
int大小跟编译器有关,在32位CPU上用TC2.0,int还是2字节,int == short int。
long的长度是C规定的,就是4字节,不管在什么编译器上都一样。
|
在嵌入领域,这个问题很必要。2038年,我快70岁了,但是我写的程序可能还在运行。可怕。
|
放心吧, 等咱们死的时候, 40多亿(unsigned long)是用不完的.
数据类型跟操作系统和运行库有关.
数据类型跟操作系统和运行库有关.
|
数据类型好像跟编译器有关系。
int有的是2个字节,有的是4个字节。
到底是跟机器还是跟编译器有关系,不是很清楚。
希望有人能解答,期待中!
int有的是2个字节,有的是4个字节。
到底是跟机器还是跟编译器有关系,不是很清楚。
希望有人能解答,期待中!
|
是啊
忧虑这个没有必要啊
忧虑这个没有必要啊
|
如果要考虑到这方面的问题,一个程序用上百年,就不应该依赖编译器,自己实现这套东西。
您可能感兴趣的文章:
本站(WWW.)旨在分享和传播互联网科技相关的资讯和技术,将尽最大努力为读者提供更好的信息聚合和浏览方式。
本站(WWW.)站内文章除注明原创外,均为转载、整理或搜集自网络。欢迎任何形式的转载,转载请注明出处。
本站(WWW.)站内文章除注明原创外,均为转载、整理或搜集自网络。欢迎任何形式的转载,转载请注明出处。