关于C语言getchar函数与EOF的三个技术问题咨询

让我逐个解答你的三个问题，结合C语言标准和GNU/Linux系统的实际行为来分析：

问题一：为什么按Ctrl+4会出现^\Quit (core dumped)？ #

在GNU/Linux系统中，Ctrl+4默认绑定的是SIGQUIT信号（信号编号3），这个信号的默认行为是强制终止程序并生成核心转储文件（core dump），用于事后调试程序崩溃原因。这和EOF完全是两回事：EOF是通过Ctrl+D触发的（终端输入模式下，Ctrl+D会告知系统当前输入流结束，此时getchar()会返回EOF）。而Ctrl+4是直接给程序发送终止信号，所以你会看到程序被强制退出并提示core dumped。

问题二：用char c = getchar()的程序为什么看起来“正常”终止？ #

首先得明确几个关键细节：

1. EOF在标准C中是一个int类型的常量，值通常为-1。
2. getchar()的返回值规则是：读取有效字符时，返回**unsigned char转换为int类型**的值（范围0~255）；只有遇到文件结束或读取错误时，才返回-1（EOF）。
3. 你的eof.out中调用putchar(EOF)，实际上是把int类型的-1强制转换为char类型输出。在大多数系统中，char是8位有符号类型，所以-1对应的二进制是0xFF，这个字节会被写入管道。

现在看copy.out的逻辑：当它从管道读到0xFF这个字节时，getchar()返回的是255（unsigned char转int的结果），然后赋值给char c。如果你的系统中char是有符号类型，255会被截断为-1（有符号8位的溢出规则）。当比较c != EOF时，c会被自动提升为int类型，变成-1，和EOF（-1）相等，所以循环终止，后面的内容就不会被处理和输出。

但这只是“碰巧”看起来正常，书中提到的隐患真实存在：如果输入中包含一个值为0xFF的扩展ASCII字符，getchar()返回255，赋值给有符号char时会变成-1，程序会错误地把这个字符当成EOF提前终止；如果你的系统中char是无符号类型，0xFF赋值给char后是255，提升为int还是255，和EOF（-1）不相等，程序永远不会识别到管道里的这个0xFF为EOF，会一直读到管道结束才停止——这时候你反而会看到后半部分内容也被输出，直接暴露错误。

问题三：用double c = getchar()时为什么没终止，还出现乱码？ #

核心还是围绕getchar()的返回值和类型转换逻辑：

• 当copy.out读到eof.out输出的0xFF字节时，getchar()返回255（int类型），赋值给double c后，255被转换为双精度浮点数255.0。
• 接下来比较c != EOF：EOF是int类型的-1，此时会把-1转换为双精度浮点数-1.0，显然255.0 != -1.0，所以循环不会终止。
• 程序调用putchar(c)时，double类型的255.0会被强制转换为char类型（255），这个值对应的ASCII字符是不可打印的控制字符，所以终端显示为乱码�。
• 之后程序继续读取管道里剩下的"The part after EOF\n"，正常输出这些内容，所以你看到了完整的后半部分。

这里要注意：getchar()返回的EOF是只有当输入流真正结束时才会返回的int值-1，而你通过putchar(EOF)输出的只是一个0xFF字节，不是真正的流结束标记。用double存储getchar()的返回值时，有效字符的int值（比如255）会被正确转换为double，但和EOF（-1）的比较永远不会成立，除非getchar()真的返回-1（也就是管道流结束），但你的eof.out并没有关闭流，只是输出了一个0xFF字节，所以程序会继续读后面的内容。

备注：内容来源于stack exchange，提问作者hansoko