为什么在 glibc 中不推荐使用“sys_errlist”？

Question

sys_errlist 是一个方便的数组，它允许获取静态的errno 描述。它的替代方案是strerror_r 函数，它有两种令人困惑的不兼容风格。它的 GNU 版本返回 char *，只要错误已知，它将来自上述相同的数组，或者来自用户提供的缓冲区。符合标准的strerror_r 版本改为返回int，并始终使用用户提供的缓冲区。问题是，尽管语义完全不同，这两个函数共享相同的名称，因此您基本上必须执行相当复杂的#ifdef 检查并根据您获得的版本编写两个完全不同的代码版本。除此之外，这两个函数都比sys_errlist 更糟糕，因为它们都要求调用者提供一个“足够大”的缓冲区来保存描述，即使 GNU 版本很少使用它，而且这两个函数都不允许知道缓冲区应该有多大。如果您选择使用sys_errlist，您可以简单地检查是否value >= sys_nerr 并仅在这种情况下分配缓冲区，只需通过snprintf 将Unknown error %d 放在那里即可。

鉴于strerror_r 是一个可怕的、难以理解的和低效的混乱，为什么GNU 开发人员将sys_errlist 标记为已弃用，实际上迫使人们要么使用strerrror_r，要么在每次编译代码时观察丑陋的警告？

Answer 1

strerror 和它的亲戚是本地化的。非本地化系统消息的有用性存在争议，但 glibc 的维护者遵循了主流方向（Solaris 和其他系统）。

但是：sys_errlist 已被弃用了一段时间。它不是 POSIX 接口。有些系统没有。

进一步阅读：

• Where can I find the contents of sys_errlist?
• Use strerror() or strerror_r() instead of sys_errlist and sys_nerr (fish-shell bug #1830)
• RE: sys_errlist（1999 年的 Cygwin）
• GNU Hurd/ hurd/ porting/ guidelines

这个问题已经有一段时间了，但过去的情况是某些系统没有strerror（请参阅Unix Incompatibility Notes: String and Memory Functions）。