关于C标准中gets函数被移除而非修改签名的技术问询

这个问题问得特别戳中痛点——不少C开发者刚接触C11标准时，都会懵一下：为啥标准委员会直接把gets()给砍了，而不是像你说的那样，给它加个长度参数，做成和puts()对应fputs()那样的「默认绑定stdin的简化版fgets()」？

其实核心原因主要有这几点：

• 历史包袱的无解性：如果只是修改gets()的签名，比如改成你设想的char *gets(char *s, int size);，那所有旧代码里不带长度参数的gets(s)调用都会直接编译失败——这和直接移除它的编译错误结果没差，但更糟的是，大概率会有不少图省事的开发者随便填个数字（比如gets(s, 1024)）就应付过去，完全没匹配原代码的缓冲区实际大小，反而埋下新的溢出隐患。
• 本质性的设计缺陷：gets()的问题从来不是缺个参数这么简单，它的设计从根上就完全没考虑安全——不管你缓冲区多大，输入超长就直接往缓冲区外面写，这是天生的致命漏洞，不是加个参数就能“修复”的，而是整个设计思路就错了。标准委员会在C11转向“安全优先”的理念后，更倾向于彻底淘汰这种从出生就带毒的函数。
• 引导正确的编程习惯：要是保留修改后的gets()，很多新手可能还是会图方便优先用它，而不是养成用fgets()的习惯。直接移除相当于下了死命令，强制开发者转向从设计就考虑安全的替代方案，从根源上减少缓冲区溢出这类高危漏洞的出现。

你提到的和puts()/fputs()对应的设计逻辑其实挺合理，但gets()已经被钉在“不安全代码典型”的耻辱柱上几十年了，标准委员会更希望彻底把这个反面教材清出去，而不是给它换个包装继续留在标准里。而且说白了，就算改了签名，旧代码还是得动手改，那不如直接引导大家迁移到功能更完整、安全性更有保障的fgets()上。

内容来源于stack exchange