C固件Bug分析：传递数组指针而非数组给函数的潜在风险

先明确代码中的核心问题：你传入的&devinfo是指向长度为4的uint8_t数组的指针（类型为uint8_t (*)[4]），而spi_read_bytes函数要求的参数类型是uint8_t*（单个字节的指针）。这种类型不匹配属于C标准中的未定义行为，当前调试正常只是巧合，潜在风险不容忽视，具体分析如下：

一、当前程序正常的原因 #

在几乎所有平坦内存模型的系统（包括绝大多数嵌入式平台）中，数组的起始地址和数组首元素的地址数值完全相同：

• devinfo作为数组名，会自动退化为指向首元素的指针（&devinfo[0]），地址数值是数组第一个字节的位置；
• &devinfo是指向整个数组的指针，地址数值同样指向数组的起始位置。

因此函数spi_read_bytes用这个地址去读写4个字节时，刚好操作的就是devinfo数组的空间，所以暂时没出现异常。

二、潜在的致命风险 #

1. 内存布局或架构变化引发的地址错误 #

如果后续代码调整了内存布局（比如添加全局变量、修改编译器对齐参数），或者在非平坦内存模型的架构上运行，数组指针和字节指针的地址解析逻辑可能出现差异。此时函数读写的内存区域会偏离devinfo数组，直接导致数据篡改、程序崩溃，甚至硬件异常。

2. 编译器优化导致的未定义行为 #

C标准明确规定，不同类型指针的隐式转换属于未定义行为。编译器可能会针对uint8_t*类型做特定优化（比如假设指针按字节对齐、无额外内存跨度），而数组指针的类型信息可能在编译过程中引发意外的优化逻辑。后续代码迭代或编译器升级后，可能出现无法复现的崩溃、数据乱码等问题，排查难度极高。

3. 指针运算逻辑错误（极端场景） #

如果spi_read_bytes函数内部存在指针偏移操作（比如data += len），对于uint8_t*来说，偏移是按单个字节计算；但如果编译器因类型不匹配产生异常解析（虽然概率低，但未定义行为无边界），会把指针当作数组指针处理——此时偏移1步会跳过4个字节，直接导致读写越界，破坏其他内存区域的数据。

三、修复建议 #

必须将传参改为符合类型要求的写法：

// 两种写法等价，均为指向首元素的uint8_t*指针
spi_read_bytes(devinfo, 4, ADXL362_REG_DEVID_AD);
// 或者
spi_read_bytes(&devinfo[0], 4, ADXL362_REG_DEVID_AD);

这种写法完全符合函数参数类型要求，彻底消除所有潜在风险。

内容的提问来源于stack exchange，提问作者Jake Wachlin