操作取值超127的char出现段错误与输出差异的原因分析

首先贴出待分析的原始代码：

int main(int argc, char** argv) {
    char c1, c2;
    c1 = 100;
    c2 = 4*c1;

    printf("%d", c2);
}

两类运行现象的独立成因 #

很多人会把两个现象的成因混为一谈，实际上-112的正常输出和段错误的触发来自代码中两个完全独立的问题，分别对应C标准中的实现定义行为和未定义行为：

1. 正常输出-112的底层逻辑 #

C语言标准明确规定，普通char类型的符号属性（有符号/无符号）没有强制统一标准，完全由编译器和目标平台的ABI定义决定：

• 如果目标平台默认char为8位有符号类型，其合法取值范围为-128~127。计算过程中4*c1的结果为400，超出8位有符号整数的表示范围，编译器会自动将400截断为低8位值：400的十六进制表示为0x190，低8位为0x90，换算为有符号8位整数就是-112，和观测到的输出完全一致。
• 这一过程是合法的整数转换行为，不会引发程序崩溃，只是不同平台的char符号属性差异会让最终计算的数值存在区别。

2. 段错误的触发原因 #

段错误本质是程序触发了非法内存访问，和局部变量c1、c2的数值计算完全无关——这两个变量都是main函数栈帧上的局部变量，哪怕赋值过程出现整数截断，也只是值的变化，不会造成内存访问非法。
实际触发段错误的核心原因是代码缺失了<stdio.h>头文件，没有为printf提供显式的函数原型声明：

• 在老版本GCC兼容C89标准的编译模式下，编译器允许对未声明的函数做隐式处理，默认推断函数返回值为int、参数按默认类型提升规则传递。如果这一推断刚好和printf的实际调用约定（变参函数的寄存器、栈传参布局）匹配，程序就能正常运行。
• 在新版本GCC严格遵循C99及以上标准的编译模式下，隐式声明已经被判定为非法行为。如果目标平台的ABI对变参函数的传参规则和隐式推断的非变参函数调用约定不匹配（比如x86-64 System V ABI下，变参函数需要专门记录向量寄存器的使用数量，而非变参函数完全不需要这一步），就会出现传参布局错乱、栈内存破坏等问题，最终触发段错误。
• 只要补上#include <stdio.h>头文件，哪怕c2的计算值因为平台char符号属性差异存在区别，也不会再触发段错误。

常见认知误区澄清 #

• 整数赋值过程的截断溢出是实现定义的行为，不是未定义行为，永远不会单独触发段错误。
• 两台设备的运行结果差异不是单一原因造成的：输出-112的设备同时满足“目标平台默认char为有符号类型”“GCC对缺头文件的printf做了兼容适配”两个条件；触发段错误的设备则是因为缺头文件导致的调用约定不匹配，在调用printf时直接崩溃，和c2的最终计算值没有关系。

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