C 为什么Windows和Linux有不同的strdup实现：strdup（）和u strdup（）？

在Windows上使用

strdup

时，我发现

\u strdup

是特定于Windows的，但在Linux上运行相同的代码时，需要

strdup

而不带下划线。是否有人知道这种差异背后的历史，以及编写跨平台代码时如何处理此问题的一些信息？

POSIX规范中有几个函数，即Linux和大多数其他UNIX变体，它们不是标准C的一部分。这些函数包括

strdup

，

写入

，

读取

等

前导下划线的理由如下，取自：

通用C运行时库（UCRT）支持大多数C语言 C++库需要的标准库。它实现了C99 （ISO/IEC 9899:1999）库，但某些例外情况：通用类型 中定义的宏，以及中的严格类型兼容性 . UCRT还实现了POSIX.1的一大个子集 （ISO/IEC 9945-1:1996，POSIX系统应用程序接口） C库。然而，它并不完全符合任何特定的POSIX 标准。UCRT还实现了几个特定于Microsoft的 不属于标准的函数和宏

Visual C++的微软实现中特有的功能 在vcruntime库中找到。这些功能中有许多是为 内部使用，用户代码无法调用。有些文件是为了 用于调试和实现兼容性

< > > C++标准保留以下划线开头的名称 实现的全局命名空间。POSIX函数和 Microsoft特定的运行时库函数位于全局 命名空间，但不是标准C运行时库的一部分。那是 为什么这些函数的首选Microsoft实现具有 前导下划线。为了便于移植，UCRT还支持 默认名称，但是微软C++编译器发布了一个弃权声明。 编译使用它们的代码时发出警告。只有默认名称 已弃用，而不是函数本身。为了抑制警告， 在代码中包含任何标题之前定义_CRT_nonsdc_NO_警告 使用原始POSIX名称的

我通过使用

#define

检查程序是否为Windows编译，如果是，则创建另一个

#define

以将POSIX名称映射到Windows特定的名称来处理这个问题。您可以检查几个选项，尽管最可靠的选项可能是

\u MSC\u VER

，如果MSVC是编译器，则定义该选项

#ifdef _MSC_VER
#define strdup(p) _strdup(p)
#endif

strdup（）

不是标准的C函数，它来自POSIX。