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位变量，否则容易丢数据