为何GLIBC 2.32+的strsignal()用线程本地缓冲区仍被标记为线程不安全？

首先，strsignal()被认为非线程安全的通用原因是标准未强制要求其线程安全。该GNU C标准库函数定义于POSIX.1-2008规范，其中明确：

strsignal()函数无需保证线程安全。
由于标准未作要求，除非具体实现明确说明，否则使用该函数的代码不能假设其线程安全。例如POSIX.1-2008规范同样未要求strerror()线程安全，但GLIBC 2.32版本后该函数已变为线程安全，且man 3 strerror中已标注。

GNU Linux版本的C标准库strsignal()手册页（Linux man-pages 6.7）标注该函数为线程不安全：

┌───────────────────────────────┬───────────────┬─────────────────────────────────┐
│ Interface                     │ Attribute     │ Value                           │
├───────────────────────────────┼───────────────┼─────────────────────────────────┤
│ strsignal()                   │ Thread safety │ MT-Unsafe race:strsignal locale │
├───────────────────────────────┼───────────────┼─────────────────────────────────┤
│ sigdescr_np(), sigabbrev_np() │ Thread safety │ MT-Safe                         │
└───────────────────────────────┴───────────────┴─────────────────────────────────┘

但查看GLIBC源码发现，自2.32版本起strsignal()已使用线程本地缓冲区，这理应使其具备线程安全性。那么为何同版本GLIBC中strerror()被标记为MT-Safe，而strsignal()仍被标注为MT-Unsafe？此外源码中无strsignal()的区域设置相关绑定，但文档却提及可能存在区域设置线程竞争，这是否是为未来变更做前瞻性处理？

修改该行为的GLIBC提交明确说明，此次变更正是因为之前的代码非线程安全。

内容的提问来源于stack exchange，提问作者The Matt