编写C加密算法时：为何函数中用sizeof(array)触发GCC警告，main中无？

我来拆解你遇到的这两个GCC警告问题，它们其实都和C语言里数组退化为指针这个核心特性有关，咱们一个个说透：

1. 数组传入函数后直接使用block触发警告 #

在main函数里，block是实打实的uint32_t[]数组类型，编译器明确知道它的数组身份，所以直接用block（比如作为数组名参与操作）不会有任何问题。但当你把数组传给其他函数时，C语言会自动把数组名转换成指向数组第一个元素的指针——也就是说，函数参数里的block本质上是uint32_t*类型，不再是数组了。

这时候如果你直接使用block（比如编译器检测到你可能混淆了指针和数组的用法，或者试图用它做只有数组能完成的操作），GCC就会抛出警告。比如你在函数里写printf("%p", block)其实没问题，但如果是某些依赖数组类型的上下文（比如试图用它初始化另一个数组），就会触发警告。

举个直观的例子：

void process_block(uint32_t block[]) {
    // 这里的block已经是uint32_t*指针，不是数组
    if (block) { ... } // 合法操作，但如果是其他数组专属操作会告警
}

解决思路：如果函数需要数组的相关信息，要么额外传入数组长度作为参数，要么用「指针+长度」的组合明确意图，避免编译器对你的操作产生误解。

2. sizeof(array)在函数里警告，main里没问题 #

同样还是数组退化为指针的锅：

• 在main函数里，block是数组类型，sizeof(block)计算的是整个数组的字节大小（比如uint32_t block[8]的话，就是8 * sizeof(uint32_t)）。
• 但在其他函数里，参数block已经变成了指针，sizeof(block)计算的是指针变量本身的大小（32位系统是4字节，64位是8字节），这几乎肯定不是你想要的结果。GCC会检测到这个操作不符合你的预期，所以抛出警告提醒你。

解决方法：永远不要依赖函数参数里的数组来获取长度，必须手动把数组长度作为额外参数传给函数。比如：

void process_block(uint32_t block[], size_t block_len) {
    // 用传入的block_len处理数组，而非sizeof(block)
}

// 调用时主动传入数组长度
int main(void) {
    uint32_t block[8];
    process_block(block, sizeof(block)/sizeof(block[0]));
}

总结一下，这两个问题都是C语言数组传参的经典陷阱，记住数组作为函数参数时会自动转成指针，就不会再踩这些坑啦。

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