时间戳

首页 > 解决方案 > 从阵列投射会导致某些 MCU 崩溃，但不会导致其他 MCU 崩溃

c - 从阵列投射会导致某些 MCU 崩溃，但不会导致其他 MCU 崩溃

问题描述

我有一段看起来像这样的代码：

void update_clock(uint8_t *time_array)
{
    time_t time = *((time_t *) &time_array[0]); // <-- hangs
    /* ... more code ... */
}

wheretime_array是一个 4 字节的数组（即uint8_t time_array[4]）。

我正在使用 arm-none-eabi-gcc 为 STM32L4 处理器编译它。

几个月前编译它时，我没有遇到任何错误，并且代码在我所有的测试 MCU 上运行得非常好。回到这个项目时，我对我的环境（OpenSTM32）进行了一些更新，现在这段代码在一些 MCU 上崩溃，而在其他 MCU 上运行良好。

我仍然有几个月前的二进制文件，并确认此代码路径在我所有的 MCU 上都可以正常工作（我有大约 5 个要测试），但现在它可以在其中两个上工作，同时导致三个他们。

我已经通过重写这样的代码来缓解这个问题：

time_t time = (
        ((uint32_t) time_array[0]) << 0 |
        ((uint32_t) time_array[1]) << 8 |
        ((uint32_t) time_array[2]) << 16 |
        ((uint32_t) time_array[3]) << 24
);

虽然这目前可行，但我认为旧代码看起来更干净，而且我还担心如果此代码路径挂起，我可能会在其他地方遇到类似的错误。

有谁知道是什么原因造成的？我可以更改设置中的任何内容以使编译器再次以旧方式工作吗？

标签： cstm32

解决方案

从版本 7-2017-q4-major 开始，arm gcc 附带 newlib 编译时time_t定义为 64 位 ( long long) 整数，导致假定它为 32 位的代码出现各种问题。您的代码正在读取源数组的末尾，将存储在那里的任何内容作为时间值的高位，可能导致大爆炸之前或宇宙热寂之后的日期，这可能不是您的代码期望什么。

如果已知源数组包含 32 位数据，则​​先将其复制到 32 位int32_t变量中，然后您可以将其分配给 a time_t，这样无论time_t.

推荐阅读