为何glibc头文件会自包含？以strings.h为例求解

1. 先理清两个头文件的本质差异 #

• <string.h>是C标准强制规定的头文件，提供strcpy、strlen这类通用字符串处理函数，完全跨平台可移植。
• <strings.h>是POSIX标准定义的扩展头文件，包含strcasecmp、strncasecmp这类大小写不敏感的字符串操作函数，不属于C标准范畴，仅在POSIX兼容系统中可用。

2. 源码中<strings.h>自包含的原因 #

你看到的glibc-2.18源码里string/strings.h仅写了#include <string/strings.h>，这是glibc构建体系里的兼容占位手段：

• glibc的源码目录结构和最终安装到系统的头文件结构不一样，这个文件是为了保证源码目录结构的完整性，适配构建脚本的路径逻辑。在实际编译安装glibc时，这个文件会被替换成真正包含函数声明和头部保护的版本，或者编译器的头文件搜索路径会优先指向存放实际内容的位置，不会触发递归包含。
• 这类转发头文件在glibc里很常见，主要是为了适配不同平台的头文件搜索习惯，以及兼容历史版本的代码结构。

3. 是否会引发严重问题？ #

正常开发场景下完全不会：

• 普通用户使用的是系统安装目录（比如/usr/include）下的<strings.h>，这个版本是经过glibc构建处理后的，有正常的头部保护宏（比如#ifndef __STRINGS_H）和完整的函数声明，不存在递归包含问题。
• 只有当有人错误地直接包含glibc源码目录里的这个string/strings.h时，才会触发无限递归包含，导致编译报错（编译器会提示包含深度超出限制），但这种情况几乎不会发生——没人会直接引用源码目录里的头文件做开发。

4. glibc中这类代码的普遍性 #

glibc里这类看似“奇怪”的转发头文件很多，目的都是为了简化构建流程、适配不同平台的编译环境，同时保证头文件在各种搜索路径下都能被正确找到，属于工程实现层面的妥协，不影响实际使用。

内容的提问来源于stack exchange，提问作者Mr. learning