1. 那个烦人的C4996警告到底从哪来的不知道你有没有遇到过这种情况刚学C语言兴冲冲地在Visual Studio里写了个scanf准备接收用户输入结果一编译满屏的警告。警告信息长得要命核心意思就是告诉你scanf这个函数不安全建议你用scanf_s或者用_CRT_SECURE_NO_WARNINGS来关掉这个警告。我第一次碰到这个警告的时候整个人是懵的。代码明明是从教科书上抄的老师也是这么教的怎么到你这儿就“不安全”了这感觉就像你规规矩矩地开车突然被交警拦下来说你的驾驶方式“存在安全隐患”建议你使用一种你没听说过的“安全驾驶模式”不然就给你个警告。心里肯定是一万个不服气对吧这个警告的编号是C4996它属于“弃用警告”。微软在它的C运行时库CRT里把一些他们认为不安全的函数比如scanf,strcpy,gets等标记为“deprecated”弃用。意思是这些函数还能用但我们不推荐你用未来可能就不支持了。编译器看到你用了这些函数就会像唐僧一样念经提醒你换掉。那为什么说它们不安全呢以scanf为例它的经典问题是缓冲区溢出。如果你定义了一个长度为10的字符数组却用scanf读入了超过10个字符多出来的部分就会写到数组后面的内存里这可能会覆盖掉其他重要数据甚至被恶意利用来执行攻击代码。scanf_s这类“安全版本”的函数通常要求你多传一个参数来指定缓冲区大小从机制上避免这种溢出。所以微软的初衷是好的是为了推动大家写出更安全的代码。但对于初学者或者在一些明确可控的内部场景下这个警告就显得有点“过度保护”了严重干扰了学习或调试的注意力。这时候_CRT_SECURE_NO_WARNINGS这个宏就登场了它的唯一使命就是让编译器闭嘴别再唠叨C4996了。2. 宏定义的位置为什么这么关键按照原始文章里提到的现象我们来做个小实验。假设我们有这么一段简单的代码#define _CRT_SECURE_NO_WARNINGS #include stdio.h int main() { int num; printf(请输入一个数字); scanf(%d, num); printf(你输入的是%d\n, num); return 0; }编译这段代码你会发现世界清净了没有C4996警告。但是如果你把宏定义和头文件包含的顺序调换一下#include stdio.h #define _CRT_SECURE_NO_WARNINGS int main() { // ... 同样的代码 }再编译那个烦人的警告又出现了为什么顺序一变效果就天差地别这里就涉及到C/C编译的一个核心过程预处理。编译器在真正编译你的.c文件之前会先由一个叫“预处理器”的家伙来处理一遍。预处理器干的活儿包括展开宏、处理条件编译、包含头文件等。关键点在于这些操作是顺序执行的。当预处理器看到#include stdio.h时它会直接去找到stdio.h文件并把里面的内容“粘贴”到当前文件#include所在的位置。stdio.h里面又包含了其他头文件层层嵌套。在这些头文件里早就写好了对scanf等函数的声明以及生成C4996警告的相关逻辑。重点来了生成警告的逻辑是在头文件内部通过条件编译宏_CRT_INSECURE_DEPRECATE来实现的。而这个宏的定义会检查_CRT_SECURE_NO_WARNINGS是否已经被定义。第一种情况先#define在预处理器处理到#include stdio.h之前_CRT_SECURE_NO_WARNINGS已经被定义了。那么当它展开stdio.h遇到里面的_CRT_INSECURE_DEPRECATE宏时因为检测到_CRT_SECURE_NO_WARNINGS已定义所以该宏被定义为一个空实现。后续所有被标记的函数如scanf展开时都不会产生警告文本。第二种情况后#define预处理器先处理#include stdio.h。此时_CRT_SECURE_NO_WARNINGS还未定义所以_CRT_INSECURE_DEPRECATE宏被定义为那个会产生警告信息的复杂版本。等之后处理器再看到#define _CRT_SECURE_NO_WARNINGS时为时已晚头文件里的“坑”已经挖好了警告生成的逻辑已经确立。这就好比你要去参加一个禁止穿短裤的会议。第一种情况是你在家先换好长裤先定义宏然后进入会场包含头文件自然畅通无阻。第二种情况是你穿着短裤先冲进了会场先包含头文件会场规则已经对你生效了保安编译器已经盯上你了这时候你才想起来从包里掏出长裤穿上后定义宏但保安已经看到你违规了警告已经记录在案。所以记住这个黄金法则如果你想用_CRT_SECURE_NO_WARNINGS来全局禁用安全警告必须确保它在所有可能引发警告的CRT头文件被包含之前定义。最稳妥的做法就是把它放在所有#include指令之前或者直接通过编译器命令行参数或项目属性来定义。3. 深入头文件看看宏到底玩了什么魔术光知道顺序重要还不够我们得亲眼看看这个“魔术”是怎么变的。就像原始文章里做的那样我们可以直接“解剖”头文件。以Visual Studio 2019为例找到你的stdio.h文件通常在VC安装目录的include文件夹下用文本编辑器打开。当然在IDE里更简单。就像原文说的在代码编辑器中对着#include stdio.h这一行右键选择“转到文档”或“打开文档stdio.h”不同IDE措辞可能不同。这会直接打开编译器使用的那个stdio.h文件。在这个文件里搜索scanf你会找到它的函数声明。我电脑上的版本里它看起来类似这样_Check_return_opt_ _CRT_INSECURE_DEPRECATE(scanf_s) int scanf( _In_z_ _Scanf_format_string_ char const* const _Format, ...);看函数声明前面有一串“装饰”其中最关键的就是_CRT_INSECURE_DEPRECATE(scanf_s)。这可不是注释而是一个宏它的作用就是给这个函数“贴上”一个“不安全建议用xxx替代”的标签。接下来我们按照原文的指引找到这个宏的定义。在VS里你可以把光标放在_CRT_INSECURE_DEPRECATE上然后按下F12转到定义或者右键选择“转到定义”。你会跳转到类似corecrt.h这样的基础头文件中看到它的真面目#ifdef _CRT_SECURE_NO_WARNINGS #define _CRT_INSECURE_DEPRECATE(_Replacement) #else #define _CRT_INSECURE_DEPRECATE(_Replacement) _CRT_DEPRECATE_TEXT( This function or variable may be unsafe. Consider using #_Replacement \ instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. \ See online help for details.) #endif谜底全部揭晓了这个宏的定义是一个典型的条件编译块如果_CRT_SECURE_NO_WARNINGS已经被定义了那么_CRT_INSECURE_DEPRECATE(_Replacement)这个宏就被定义为什么都不做的空宏。于是在scanf声明前的_CRT_INSECURE_DEPRECATE(scanf_s)在预处理后就被替换为空相当于这个“不安全标签”被撕掉了编译器自然就不会为它产生警告。如果_CRT_SECURE_NO_WARNINGS没有被定义那么_CRT_INSECURE_DEPRECATE(_Replacement)就被定义为一个会展开成_CRT_DEPRECATE_TEXT(...)的宏。后面那一长串用引号括起来的字符串正是我们看到的C4996警告信息#_Replacement是一个“字符串化”操作符会把传入的参数这里是scanf_s变成字符串scanf_s拼接进警告信息里。所以整个链条是这样的#define _CRT_SECURE_NO_WARNINGS- 预处理器标记该宏已定义 - 展开头文件时_CRT_INSECURE_DEPRECATE宏被定义为空 -scanf等函数声明前的该宏被替换为空 - 编译器看不到“不安全标签” - 不产生C4996警告。没有定义该宏 -_CRT_INSECURE_DEPRECATE宏被定义为生成警告文本 -scanf等函数声明被“贴上标签” - 编译器看到标签 - 产生C4996警告。4. 除了宏还有哪些“消音”大法知道了原理我们就能灵活选择关闭警告的方法了。#define _CRT_SECURE_NO_WARNINGS只是最直接的一种但并不是唯一和最好的。在实际项目中我们需要根据场景选择合适的方法。4.1 项目级设置推荐对于整个项目在Visual Studio中设置是最干净、最一劳永逸的方法也避免了源码中到处写#define的混乱。在“解决方案资源管理器”中右键点击你的项目选择“属性”。在属性页中依次进入“配置属性” - “C/C” - “预处理器”。在右侧的“预处理器定义”这一栏点击编辑。在已有的定义列表末尾注意不要破坏已有的添加_CRT_SECURE_NO_WARNINGS。多个定义用分号隔开。点击确定应用。这样该项目下所有源文件在编译时都会自动定义这个宏。优点全局生效不影响源代码整洁度。新加入的源文件也自动享受“清净”。缺点只对当前项目有效。如果你有多个项目需要分别设置。4.2 编译器命令行参数这和项目设置本质是一样的只是操作界面不同。你可以在编译器的命令行里直接添加/D_CRT_SECURE_NO_WARNINGS参数/D是定义宏的意思。在VS的项目属性页“配置属性” - “C/C” - “命令行”的“其他选项”里你也可以手动添加这个参数。优点非常直接适合在构建脚本如CMakeLists.txt或自动化编译流程中使用。缺点对新手不够友好需要知道命令行参数格式。4.3 在源代码中定义需注意位置这就是我们开头讨论的方法。务必记住要放在所有头文件之前。通常我们会创建一个单独的“预编译头文件”比如stdafx.h或pch.h在里面定义这类全局宏然后确保每个源文件第一个包含的就是它。// 在 stdafx.h 或 pch.h 的最开头 #define _CRT_SECURE_NO_WARNINGS #define _CRT_NONSTDC_NO_WARNINGS // 如果需要禁用其他类似警告也可以加上 // 然后再包含其他标准头文件 #include stdio.h #include stdlib.h #include string.h优点明确在代码中可见。缺点容易因顺序问题失效如果多个源文件忘记包含该头文件就会出问题。4.4 局部禁用警告精准打击有时候你只是在一个特定的、确认安全的场景下使用了某个“不安全”函数不想全局禁用警告以免错过其他真正有风险的警告。这时可以使用编译器特有的#pragma指令来局部禁用。在Visual Studio中可以在函数前后这样写#pragma warning(push) // 保存当前的警告状态 #pragma warning(disable: 4996) // 仅禁用C4996警告 // 这里使用 scanf不会产生警告 int x; scanf(%d, x); #pragma warning(pop) // 恢复之前的警告状态优点影响范围最小只针对特定代码段不会掩盖其他问题。体现了“精准管理”的思想。缺点代码会变得有些冗长如果用的地方多会显得很乱。4.5 改用安全函数治本之策最后也是最符合微软期望的做法真的去使用那些安全函数比如把scanf换成scanf_s把strcpy换成strcpy_s。这些_s后缀的函数通常要求你多传递一个表示目标缓冲区大小的参数。char buffer[10]; // 使用 strcpy_s明确指定最多拷贝多少字符包括结尾的\0 strcpy_s(buffer, sizeof(buffer), hello);优点从根本上提高了代码的安全性是良好的编程习惯。缺点这些_s函数是微软的扩展不是标准C/C库的一部分。这意味着你的代码可能在其他编译器如GCC、Clang上无法编译降低了可移植性。这也是很多人宁愿禁用警告也不愿换函数的一个重要原因。5. 理解_CRT_DEPRECATE_TEXT警告信息的最终组装者我们回溯一下宏展开的链条。当_CRT_SECURE_NO_WARNINGS未定义时_CRT_INSECURE_DEPRECATE(scanf_s)展开为_CRT_DEPRECATE_TEXT(...警告信息...)。那么这个_CRT_DEPRECATE_TEXT又是什么呢继续在头文件里追踪它的定义选中后按F12你可能会看到类似这样的代码#define _CRT_DEPRECATE_TEXT(_Text) __declspec(deprecated(_Text))这行代码是关键中的关键__declspec(deprecated(...))是微软编译器的一个特殊声明修饰符。它的作用就是告诉编译器被我修饰的这个函数或变量、类等已经“弃用”了。括号里的_Text参数就是当用户使用这个被弃用的东西时编译器应该抛出的警告信息。所以整个流程的终极形态是_CRT_INSECURE_DEPRECATE(scanf_s)展开为_CRT_DEPRECATE_TEXT(...Consider using scanf_s...)。_CRT_DEPRECATE_TEXT再展开为__declspec(deprecated(...Consider using scanf_s...))。这个__declspec(deprecated)修饰符被加到scanf的函数声明上。编译器在编译时看到某个函数被__declspec(deprecated)修饰就会触发“弃用警告”C4996并把括号里的字符串作为警告信息显示出来。这下就完全通了。宏在这里扮演了一个“开关”和“信息组装者”的角色而最终的警告是由编译器的底层机制__declspec(deprecated)发出的。这种设计非常巧妙它把“是否警告”的逻辑通过#ifdef和“如何警告”的机制通过__declspec分离开使得代码非常灵活和可配置。6. 举一反三其他类似的“消音”宏理解了_CRT_SECURE_NO_WARNINGS的机制你就能举一反三处理Visual Studio中其他类似的“唠叨”警告了。微软的编译器有一系列类似的宏用于控制特定类别的警告。_CRT_NONSTDC_NO_WARNINGS这个非常常用。它用于禁用那些“建议使用POSIX标准名称”的警告。比如微软提供了一些POSIX标准的函数如read,write,open等但它们的名字可能和标准略有不同或者微软希望你用自己的一套。当你使用这些POSIX风格函数时编译器可能会警告你“这不是标准C函数”。定义这个宏可以关闭这类警告。_SCL_SECURE_NO_WARNINGS这个宏是针对微软的C标准库STL中的安全检查警告。早期版本的Visual C STL有一些扩展的安全检查功能会针对某些用法如迭代器越界产生警告。定义这个宏可以关闭这些安全检查相关的警告。_ATL_SECURE_NO_WARNINGS同理这是针对Active Template Library (ATL) 中的安全警告。这些宏的工作原理大同小异都是在对应的头文件如stdio.h,io.h,vector,atlbase.h里通过条件编译来开启或关闭某些会产生警告的代码段或声明修饰符。查找和学习的技巧当你遇到一个顽固的、关于“不安全”或“弃用”的警告并且警告信息里提到了一个宏名比如“To disable deprecation, use XXX”那么这个XXX很可能就是控制这个警告的宏。你可以尝试在项目属性中定义它或者去对应的头文件里搜索这个宏看看它是如何通过#ifdef来控制警告生成的这能让你对编译器的行为有更深的理解。7. 最佳实践与个人心得折腾了这么一大圈从被警告烦到到研究怎么关掉它再到深入头文件看它的实现机制最后了解各种关闭方法。我想分享几点在实际开发中的心得第一不要无脑全局禁用。刚开始学或者做一个快速原型图个省事全局定义_CRT_SECURE_NO_WARNINGS没问题。但在正经的、尤其是可能对外发布的项目中安全警告的存在是有意义的。它们像代码里的“安检仪”虽然有时候误报你觉得安全但它能帮你发现很多潜在的、真正的缓冲区溢出漏洞。我建议在项目属性里保持警告开启然后对于你经过评估、确认安全的特定使用场景使用#pragma warning(disable: 4996)局部禁用。这样既能保证大部分代码受到检查又让特殊用例通过。第二理解警告背后的原因。就像我们剖析scanf一样每个安全警告背后都对应着一种特定的编程风险。strcpy可能导致缓冲区溢出gets更是臭名昭著早已从C标准中移除。即使你决定禁用警告也一定要明白你用的这个函数为什么会被认为不安全你的使用场景是否真的规避了这种风险。知其然更要知其所以然。第三考虑可移植性。如果你写的代码需要在LinuxGCC/Clang或Mac上编译那么大量使用微软特有的_s安全函数就不是个好主意。这时候你有几个选择1) 使用条件编译在Windows下用_s函数在其他平台用标准函数或对应的安全版本如snprintf2) 放弃_s在所有平台上都使用标准函数但自己编写安全的封装函数或者在调用处严格进行边界检查3) 使用第三方跨平台的安全字符串库。第四保持头文件清洁。尽量不要在业务逻辑的源文件里随意写#define _CRT_SECURE_NO_WARNINGS。把它放在项目设置里或者一个统一的、所有源文件最先包含的配置头文件里。这能让你的代码更干净也避免了因顺序问题导致的诡异bug。说到底_CRT_SECURE_NO_WARNINGS不仅仅是一个用来消除警告的魔法字符串。它是一扇窗户透过它你可以看到C/C编译器预处理机制、条件编译、声明修饰符、以及库函数安全设计等多个层面的知识。下次再看到C4996警告时你或许不会再感到烦躁而是会心一笑知道自己有若干种方法可以优雅地应对它并且清楚每一种方法背后的代价和收益。这才是从“会用”到“理解”的进阶。