1、发现问题
平台1:win64位系统,win32程序,正常运行
平台2:linux32位系统,linux32程序,数据丢失
1.1、获取ms级别时间戳时,同样的函数接口windows32的程序运行ok,数据也正常,在linux平台上则无法正常使用,且数据只有低4字节的数据,如下:
原始数据:1594795490627
丢失后的数据:1362623811
{ struct timeval stTimeValue; uint64_t ulUTC = 0; ///[jxl|2020年7月15日14:59:31] | 返回从纪元年开始到现在的秒和毫秒 gettimeofday( &stTimeValue, NULL ); ulUTC = 1000*stTimeValue.tv_sec + stTimeValue.tv_usec/1000; printf("UTC Time_stamp_ms[%llu]\r\n", *pulUTC); }
2、探索问题过程
2.1、原本以为是格式化输出的问题,查询man手册,查看glibc的源码,我当前的输出没有毛病%llu
2.2、通过赋值常量 uint64_t ulTestValue = 1594793470857;测试程序如下:
{ uint64_t ulTestValue = 1594793470857; printf("ulTestValue [%llu] \r\n", ulTestValue ); }
输出的结果为: ulTestValue [1594793470857] 说明:%llu的输出是没有问题,问题在运算赋值部分
3、验证猜测
3.1、增加强制转换,代码如下:
{ struct timeval stTimeValue; uint64_t ulUTC = 0; ///[jxl|2020年7月15日14:59:31] | 返回从纪元年开始到现在的秒和毫秒 gettimeofday( &stTimeValue, NULL ); ulUTC = (uint64_t)1000*stTimeValue.tv_sec + (uint64_t)stTimeValue.tv_usec/1000; printf("UTC Time_stamp_ms[%llu]\r\n", *pulUTC); }
输出的结果为: UTC Time_stamp_ms[ 1594796213137 ],数据正常未丢失。
4、结论:
在当赋值结果的存储为64bit时,为了确保数据完整性,请强制转换成64位的变量进行运算
备注:曾经在什么地方看到过,算术运算若在32位系统上运算时默认参与运算的是32位的数据,对于超过32位的计算结果要强制转换成64位变量,否则容易丢数据