关于GLib是否属于C标准规定的实现及其标识符合规性的技术问询

嘿，这个问题抓得很准，咱们把它拆成两部分来聊：

一、GLib是不是C标准规定的“实现”？ #

答案很明确：完全不是。

C标准里提到的“实现”，特指编译器（比如GCC、Clang这类）以及配套的标准库（像glibc、musl、MSVC的CRT）——这些是直接为C语言标准提供支持的核心组件。而GLib是GNOME项目开发的第三方实用库，它的作用是给C语言补充标准里没有的高级数据结构（比如链表、哈希表）、工具函数、跨平台支持等，属于上层的应用级库，和C标准的“实现”完全是两回事。

二、那_g_list_remove_link违反C标准的保留标识符规则吗？ #

先把你引用的C23标准规则摆出来：

C23 6.4.2.1.7 Some identifiers are reserved. All identifiers that begin with a double underscore ( __ ) or begin with an underscore ( _ ) followed by an uppercase letter are reserved for any use, except those identifiers which are lexically identical to keywords.) All identifiers that begin with an underscore are reserved for use as identifiers with file scope in both the ordinary and tag name spaces. Other identifiers may be reserved, see 7.1.3

从标准的字面严格定义来看，第三方库（非实现）确实不应该使用以下划线开头的文件作用域标识符。但这里有个关键细节：_g_list_remove_link是用static inline定义的——static修饰符让这个函数变成了内部链接，它的作用域仅限于定义它的单个源文件，根本不会暴露到全局命名空间里。

GLib开发者这么做，是把下划线开头作为内部私有接口的命名约定，用来区分对外公开的API和库内部自用的函数。而且因为static的限制，这个标识符不会和全局范围内的任何标识符（包括编译器/标准库的保留标识符）冲突，实际使用中完全不会触发标准里禁止的问题。

简单说：从标准字面看有点擦边，但实际因为作用域被限制，既不会违反标准的核心意图（避免命名冲突），也不会给使用者带来问题。

内容来源于stack exchange