ISO C保留了某些标识符以供将来扩展（参见此处），包括以“str”开头的任何内容。

IMNSHO，这是微软的说法“不要把Unix软件放在Windows机器上”。这个问题有几个令人沮丧的方面：

1. strcmpi()不是一个POSIX函数-相关的函数在<strings.h>中定义，称为strcasecmp()等。
   1.即使您显式请求支持POSIX函数，Microsoft也认为您不能使用POSIX名称，而必须在它们前面加上可怜的下划线。
2. AFAIK，没有一种方法可以覆盖MSVC编译器对这个问题的看法。
   也就是说，GCC工具链在某些函数上有点难以驾驭--mktemp()等。然而，尽管有警告（这是合理的），它还是成功地编译和链接了。
   我注意到MSVC也有一个关于snprintf()等的蜜蜂。如果他们的函数符合C99标准（沿着编译器的其他部分），那么就不会有任何溢出的风险--标准要求空终止，这与微软的说法相反。
   我没有一个真正好的解决这个问题的办法--我不确定是否有。一种可能性是创建一个头（或一组头），将所有实际的POSIX名称Map到Microsoft对它们的误解。另一种方法是创建一个带有正确POSIX名称的普通函数库，每个函数都调用该名称的Microsoft版本（给你一个四行函数的大集合-声明符行，一个左括号，一个右括号和一个调用POSIX函数名称的Microsoft变体的return语句。
   有趣的是，Microsoft API调用也会污染用户的名称空间，但却没有被弃用或重命名。

以下划线和小写字母开头的名称如果在全局命名空间中声明，则由C标准为C实现保留。这可以防止它们与您自己的代码中的类似名称冲突，您自己的代码不能使用此命名约定。

strcmpi在Visual C++ 2008中完全消失了，所以如果你打算升级，你一定要注意弃用。
_并没有使函数成为ISO标准，只是随着语言的发展，添加以_开头的函数更安全，因为这是为语言保留的命名空间的一部分。
根据Microsoft's documentation for _stricmp的说法，听起来strcmpi有一些做法会导致一些不直观的排序（包括规范化为小写，而不是简单地将大小写视为不相关）。听起来_stricmp需要更多的努力来做人们自然期望的事情。

保持POSIX兼容性的方法：

// Check if on MS compiler (newer than Visual Studio 2015)
#if ( _MSC_VER > 1900 )
// redefine the name
#ifndef stricmp
#define stricmp _stricmp
#endif
#endif // _MSC_VER