libc++是否维护内部状态

Does libc++ maintain an internal state?

本文关键字：状态内部维护是否 libc++ 更新时间：2023-10-16

libc++是否保持一个进程范围的内部状态，在该状态下，代码的一部分中发生的操作可以通过调用std:：*类（例如std:：set）来影响代码的某个遥远部分？更具体地说，我见过这样的崩溃（仅显示堆栈顶部跟踪）：

std::__1::__tree<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::__insert_unique(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 156, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)

修复方法是升级一个没有直接参与崩溃的库，以纠正C++ABI问题。我只是感到惊讶的是，ABI问题可能会产生与原因相去甚远的影响，并且想知道标准库本身是否有某种状态已损坏？

C++不提供受保护的环境。如果代码的任何部分做了一些被禁止的事情（例如，删除一个对象两次，取消数组的限制…），那么代码的任何其他地方都可以立即或长时间后做任何事情。

事实上，问题往往是错误显然不会造成任何伤害，因为程序（显然）只是简单地工作。

关于违反ABI的错误是非常低级别的（例如，可能需要机器代码来保留某个寄存器，但它没有），你不会感到惊讶。欢迎来到"未定义行为"地狱。

在特定的std::set和std::map中，在某些实现中已知它们依赖于哨兵，因此覆盖全局变量甚至会影响稍后创建的映射和集合。

此外，C++中的几乎所有东西都依赖于动态分配的内存，违反ABI的程序可能会破坏与之相关的数据结构，其影响可能会在以后表现出数百万条执行的指令（例如，当损坏的空闲块被重新分配给其他东西时）。