如何让strcpy()在目标为const指针时触发编译器错误（而非仅警告，针对Visual Studio 2019）

我来分享下针对这个问题的实践和探索——毕竟维护百万行级的跨平台老C/C++代码，既要精准抓strcpy的const目标问题，又不能乱开全局警告转错误，确实是个需要权衡的活儿。

问题背景 #

先明确核心诉求：在VS2019 Community环境下，标准strcpy(char *dest, const char *src)给const目标赋值时，只会触发C4090警告，但我们需要直接触发编译器错误；同时不能用全局的/WX（警告转错误）选项——毕竟项目从UNIX迁移到WinCE再到WinNT，积累了260+未解决的警告，全局转错误会直接导致编译失败，完全没法推进。

目前在用的可行方案 #

我试过的唯一能精准触发错误的方式，是用预处理器宏包装strcpy，通过一个小技巧检测目标是否为const：

#define xstrcpy(dest, src) strcpy((((dest)[0] = 0), (dest)), (src))

原理说明 #

这个宏的核心是利用const对象不能被赋值的特性：

1. (dest)[0] = 0：尝试给目标的第一个字节赋值，如果dest是const，这行代码会直接触发C2166错误（左值指定const对象）；
2. 逗号运算符(expr1, expr2)会返回expr2的结果，所以非const的dest会正常把自己传给strcpy，赋值操作只是做了个"const检测"，不影响最终的拷贝逻辑。

测试效果 #

用一段简单代码验证：

char name1[12] = "jubjub";
const char name2[12] = "bujbuj";

strcpy(name1, "lolo");    // 非const目标，正常通过（仅原警告逻辑）
xstrcpy(name1, "koko");   // 非const目标，正常通过
strcpy(name2, "lolo");    // const目标，仅触发C4090警告
xstrcpy(name2, "koko");   // const目标，直接触发C2166错误（达到预期）

对这个宏的疑问解答 #

你担心的几个点其实都不是大问题：

• 空指针情况：如果dest是空指针，(dest)[0] = 0本身会触发崩溃，但空指针调用strcpy本来就是未定义行为，这个宏只是提前暴露了问题，没引入新风险；
• 编译器内联优化：这种简单的逗号表达式和赋值操作，VS2019的编译器完全能正确识别并优化，不会影响代码的执行效率或内联效果。

用C11 _Generic尝试的替代方案 #

后来我想到C11的_Generic可以做类型匹配，尝试做更"标准"的类型安全检测，最初写了这个宏：

#define strcpy(d, s) _Generic((d), \
    char *: strcpy((d), (s)), \
    char * const : strcpy((d), (s)) \
)

但测试发现，数组类型（比如char name1[12]）会被识别为char [12]，而不是char*，导致触发E2535错误（无匹配的选择器类型）。

改进后的_Generic方案 #

后来给数组类型加了匹配项：

#define strcpy(d, s) _Generic((d), \
    char *: strcpy((d), (s)), \
    char [sizeof(d)]: strcpy((d), (s)), \
    char * const : strcpy((d), (s)) \
)

测试不同场景的结果：

char name1[12] = "jubjub";
const char name2[12] = "bujbuj";
char* pName = name1;
const char* pNamea = name1;
char* const pNameb = name1;
const char* const pNamec = name1;

strcpy(pName, "lolo");    // 正常通过
strcpy(pNamea, "lolo");   // 报错：无匹配const char*类型（符合预期）
strcpy(pNameb, "lolo");   // 正常通过（const指针指向非const内存，允许修改）
strcpy(pNamec, "lolo");   // 报错：无匹配const char* const类型（符合预期）
strcpy(name1, "koko");    // 正常通过
strcpy(name2, "lolo");    // 报错：无匹配const char[12]类型（符合预期）

这个方案的局限性 #

虽然类型匹配更精准，但有两个硬伤不适合老代码场景：

1. 依赖C11标准：如果项目里还有兼容老编译器的代码（比如之前的VS2005/2017），_Generic会直接报错；
2. 重定义strcpy风险：直接把标准库的strcpy宏替换，可能和头文件、其他第三方代码的定义冲突，引发意外问题。

方案总结 #

对比下来，那个利用赋值检测const的xstrcpy宏是最适合老代码项目的：

• 兼容性好：不依赖C11，在VS2005到VS2019都能正常工作；
• 风险可控：不需要替换所有strcpy调用，可以逐步把需要检查的地方换成xstrcpy；
• 精准触发：只在目标是const时报错，完全符合我们的诉求。

内容来源于stack exchange