为什么ISO/IEC9899不规范C标准库中的函数定义？
Why does ISO/IEC 9899 not standardize the definitions of the functions in the C standard library?
ISO:IEC 9899 标准化了 C 标准库函数的原型并描述了它们的行为。它指定了某个 C 标准函数的标识符、return 类型和与其匹配类型的参数。
但是为什么它没有指定定义-（核心具体功能实际上是如何工作的）？
为什么 C 标准库函数 X 的实际源代码可能与 f.e 不同。 Linux 上的 gcc 编译器套件（GNU C 库）、macOS 上的 clang 套件和 Windows 上 Microsoft Visual C++ 的核心系统动态库？为什么它取决于实现、操作系统和相关的编译器设计？
编辑：
我知道这个问题乍一看对你们中的大多数人来说似乎很糟糕，但它绝对有权得到回答，因为我还不知道这样做的原因。
我不建议 ISO 对定义进行标准化，因为这个问题是基于意见而结束的——不要误会我的意思。我只是问为什么是这样的事情，想从你的知识和经验中学习。
以strlen为例。如果ISO C标准规范了这个函数的定义，大概会是这样：
size_t strlen(char *s)
{
size_t l = 0;
while(s[l]) l++;
return l;
}
这是非常低效的。 GNU C 库有用汇编和 C 编写的实现，速度非常快，但不可移植。
有些功能可能无法标准化。例如，它如何定义putchar、vfprintf和fwrite？ longjmp 之类的汇编函数呢？或者 "macros" 喜欢 setjmp?
可能会利用其他定义。例如，如果标准 C 委员会将 memcpy 标准化，则会发生两件事：
人们可以滥用复制顺序，并且
现有实施将失效。
ISO:IEC 9899 标准化了 C 标准库函数的原型并描述了它们的行为。它指定了某个 C 标准函数的标识符、return 类型和与其匹配类型的参数。
但是为什么它没有指定定义-（核心具体功能实际上是如何工作的）？
为什么 C 标准库函数 X 的实际源代码可能与 f.e 不同。 Linux 上的 gcc 编译器套件（GNU C 库）、macOS 上的 clang 套件和 Windows 上 Microsoft Visual C++ 的核心系统动态库？为什么它取决于实现、操作系统和相关的编译器设计？
编辑： 我知道这个问题乍一看对你们中的大多数人来说似乎很糟糕，但它绝对有权得到回答，因为我还不知道这样做的原因。
我不建议 ISO 对定义进行标准化，因为这个问题是基于意见而结束的——不要误会我的意思。我只是问为什么是这样的事情，想从你的知识和经验中学习。
以strlen为例。如果ISO C标准规范了这个函数的定义，大概会是这样：
size_t strlen(char *s)
{
size_t l = 0;
while(s[l]) l++;
return l;
}
这是非常低效的。 GNU C 库有用汇编和 C 编写的实现，速度非常快，但不可移植。
有些功能可能无法标准化。例如，它如何定义putchar、vfprintf和fwrite？ longjmp 之类的汇编函数呢？或者 "macros" 喜欢 setjmp?
可能会利用其他定义。例如，如果标准 C 委员会将 memcpy 标准化，则会发生两件事：
人们可以滥用复制顺序，并且
现有实施将失效。