为何转换为int*的8位数据类型可用于scanf("%d")，但printf不行？

首先需要明确：你提供的测试代码属于C标准定义的未定义行为，你观测到的输出仅为特定CPU架构、编译器、栈布局下的偶然结果，不具备通用性。以下是针对你三个问题的底层原理说明：

1. 为什么直接打印a、b结果符合预期，没有触发明显的内存越界？ #

你测试的环境大概率是32位int的小端架构：

• %d对应的sscanf逻辑要求写入目标为4字节的int*，写入的数值-111的32位补码为0xFFFFFF91，9的32位补码为0x00000009。
• 小端模式下，整数的低8位会存在指针指向的首地址处，刚好是int8_t类型变量a、b占用的1字节空间，所以你单独读取a、b的1字节时，值是正确的。
• 你说的内存越界实际已经发生：sscanf写入时会覆盖指针后3字节的栈内存，只是你当前测试场景下，被覆盖的内存是栈上未使用的padding、或者未涉及返回地址等关键数据，所以没有触发程序崩溃等明显异常，只是未定义行为的一种表现。

2. 为什么*(int*)v[0]解引用后打印结果异常？ #

核心原因有两个：

1. 两次写入的内存区域重叠：a和b是相邻的1字节变量，你传入sscanf的两个int*指针仅相差1字节，第二次写入9的时候，会覆盖第一次写入-111的高3字节内容，导致从v[0]读取4字节的时候，值已经被第二次写入操作修改。
2. 违反严格别名规则：C标准不允许将int8_t*强制转换为int*后直接解引用，这种操作属于严格别名违规，编译器优化时可能会产生不符合预期的代码，进一步导致读取结果异常。

3. 是否存在编译期机制向scanf/printf传递实际数据类型信息？ #

C标准本身没有设计这类机制，scanf/printf完全依赖格式字符串判断参数类型，这也是这两类函数容易出现内存安全问题的核心原因之一。
不过主流编译器（GCC、Clang、MSVC）都做了自定义扩展：只要开启-Wformat类编译选项，编译器会在编译阶段静态检查格式字符串和后续参数的类型是否匹配，你这段代码在开启-Wall的情况下会明确报类型不匹配的警告，但这只是静态检查能力，不属于运行时传递类型信息的机制。

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