Repository navigation
[Bug] [libc] settimeofday 在 time64/long32 配置下窄化校验，错误拒绝有效时间戳 #11922
Description
RT-Thread Version
master, commit a59e72fb5c2f272761a2813fc9bd9fe18eb29d7d.
Affected area
libc / RTC, components/libc/compilers/common/ctime.c, settimeofday().
Hardware / Architecture / Toolchain
32 位 ARM ABI：time_t 为 64 位有符号类型，long 为 32 位。工具链为 GNU Arm Embedded Toolchain 10.3-2021.10（newlib）。已通过隔离的 ARM 编译验证类型大小及窄化转换行为；尚未验证已部署固件，不代表已经完成实机测试。
问题描述 / Describe the bug
settimeofday() 在验证时间戳时先强制转换为 long：
if (tv != RT_NULL && (long)tv->tv_usec >= 0 && (long)tv->tv_sec >= 0)在 time64/long32 配置下，有效的正时间戳可能因此变成负数，在调用 RTC 驱动之前就返回 -1、设置 errno=EINVAL。
复现 / Reproduction
在上述 ABI 下启用 RT_USING_RTC，并提供能接受该时间的 RTC 设备：
#include <time.h>
#include <sys/time.h>
#include <errno.h>
_Static_assert(sizeof(time_t) == 8, "requires time64");
_Static_assert(sizeof(long) == 4, "requires long32");
struct timeval tv = {0};
tv.tv_sec = (time_t)2208988800LL; /* 2040-01-01 00:00:00 UTC */
tv.tv_usec = 0;
int rc = settimeofday(&tv, NULL);预期：该有效正时间应通过入口校验，由 RTC 驱动决定是否支持设置。
源码推导结果：测试所用 ARM GCC 的 (long)2208988800LL 为 -2085978496，入口条件为假，因此两个 RTC control 操作均不会被调用，返回 -1/EINVAL。
验证边界：已隔离编译确认类型大小及强转后的判断结果，尚未在目标板上端到端执行上面的调用。超范围有符号转换的结果取决于实现；这里的数值针对已验证的 GCC 行为。并非所有 2038 年之后的时间都会被拒绝：在该行为下首个拒绝区间为秒值 2147483648..4294967295。
Suggested direction
避免为了检查符号而将 tv_sec 窄化为 long，按字段自身的类型进行范围验证。该问题不限于 picolibc，time64/long32 的 newlib 配置同样可能受影响。它与 time32 本身的表示范围限制是两个独立问题。
引入提交和版本 / Regression history
- 引入该窄化检查的提交：92859cc79e，2023-08-07，
[libc][time] silence the incorrect type warning。 - 该提交将原先直接比较字段的表达式改成
(long)强转；首个包含它的正式 release 为 v5.0.2。 - 这是条件性回归：只有字段类型与
long的宽度/表示范围不匹配并输入对应时间戳时才暴露，并非从该版本开始所有平台都不能设置时间。
其他实现参考 / Comparison
- glibc 2.42 settimeofday.c：64 位实现经
__timeval64转为__timespec64后调用时钟设置接口，不为检查符号而将秒窄化为long。 - NuttX lib_settimeofday.c：使用
ts.tv_sec = tv->tv_sec，再调用clock_settime()。
这里只比较有效正时间戳的传递方式，不主张所有 OS 的设置时间权限、负值策略或硬件支持范围相同。
Activity
github-actions commentedon Oct 23, 2026
如需认领并处理此 Issue，请评论
/claim。To claim and work on this issue, comment
/claim.Yunlk commentedon Oct 24, 2026
/claim
github-actions commentedon Oct 24, 2026
@Yunlk has claimed this issue.
Yunlk commentedon Oct 24, 2026
在 QEMU 上实测复现了，也验证了改法。边界和你说的完全一致。
环境
bsp/qemu-vexpress-a9（32 位 ARM，RT_USING_RTC=y，板上有 rtc 设备）1c801efasizeof(time_t)=8、sizeof(long)=4—— 正是 time64/long32复现（未修复）
逐点扫了一遍边界：
首个被拒值正好是
2147483648，与 issue 里写的区间一致；INT32_MAX及以下不受影响。改法
去掉强转，按字段自身类型校验：
改完同一份固件重跑，五个点全部
ret=0，INT32_MAX以下行为未变。两点补充
tv_usec的强转也一并去掉了，但它在 ILP32 上本来就没问题（suseconds_t32 位）；保留只是为了和tv_sec写法统一。如果你希望改动更小，只动tv_sec也可以。顺带发现但未改动：这里只校验了
tv_usec >= 0，没有校验 POSIX 要求的< 1000000。传tv_usec = 5000000目前会被放行并送进 RTC 驱动。这属于另一处校验缺失，是否一并收紧由维护者判断，我没有把它混进这次的改动。关于 utest
这个用例要能跑，前提是系统里有
rtc设备（_control_rtc()走rt_device_find("rtc")，找不到会直接返回-RT_ENOSYS，和强转问题是两条不同的失败路径）。CI 里 qemu-vexpress-a9 有 rtc，所以理论上可以加；但需要确认其他跑 utest 的 BSP 是否都有 rtc 设备，否则用例会因为找不到设备而误失败。如果需要，我可以把补丁提成 PR，并附一条在
-DRT_USING_RTC下条件编译的 utest（断言INT32_MAX + 1与2208988800两个值能通过）。