GCC中使用__uint128_t后调用scanf读取uint8_t引发未定义行为：不同优化级别下的行为差异及对齐影响问询

咱们直接戳破核心问题：你遇到的异常完全是代码里的未定义行为引发的，和GCC编译器本身无关。下面拆解一下具体来龙去脉：

1. scanf格式符与参数类型不匹配是根本原因 #

在你的第一段代码里，scanf("%u", &num);存在严重的类型不匹配问题：

• 格式符%u要求对应的参数是**unsigned int*类型**，用来读取一个unsigned int大小的值；
• 但num是std::uint8_t类型，取地址后是uint8_t*，本质是1字节的无符号整数指针。

根据C/C++标准，这种格式符和参数类型不匹配的情况属于未定义行为——编译器可以做任何事情，包括在不同优化级别下表现出完全不同的行为，这正是你看到的现象。

2. 不同优化级别表现不同的底层逻辑 #

• -O0（无优化）：编译器会严格按变量声明的顺序在栈上分配内存，very_long（16字节）紧跟在num（1字节）后面。当scanf用%u写入时，它会往&num的地址写入4字节（unsigned int的大小），这就会越界覆盖到very_long的前3个字节，把very_long的初始值1给冲掉了，所以最终输出0。
• -O1/-O2/-O3（优化模式）：编译器会对代码做各种优化，比如把very_long直接放在寄存器里，或者调整栈上变量的布局，让num的越界写入碰不到very_long的内存，所以very_long的值保持为1，输出符合预期。

3. 加aligned(4)后结果一致的本质是巧合 #

当你给num加上__attribute__ ((aligned(4)))属性后，编译器会把num分配到4字节对齐的地址上。此时scanf写入4字节时，后面的内存不会覆盖到very_long的空间（因为对齐后num和very_long之间有足够的填充字节），所以不管有没有优化，very_long的值都不会被破坏，输出都是1。但这只是内存布局巧合带来的“正常”结果，本质还是未定义行为，绝对不能依赖这种方式修复问题。

正确的修复方式 #

你需要让scanf的格式符和参数类型严格匹配，有两种可选方案：

方案一：修改变量类型为unsigned int #

#include <cstdio>
#include <cstdint>
int main() {
    __uint128_t very_long = 1;
    unsigned int num; // 改为unsigned int匹配%u
    scanf("%u", &num);
    printf("%llu", static_cast<uint64_t>(very_long));
    return 0;
}

方案二：使用匹配uint8_t的格式符%hhu #

#include <cstdio>
#include <cstdint>
int main() {
    __uint128_t very_long = 1;
    std::uint8_t num;
    scanf("%hhu", &num); // %hhu对应unsigned char/uint8_t
    printf("%llu", static_cast<uint64_t>(very_long));
    return 0;
}

记住：未定义行为是C/C++开发中的大忌，任何依赖未定义行为的结果都是不可靠的，必须严格遵循标准要求编写代码。

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