QuickJS-NG 项目中 Clang 20 下大整数转字符串的异常问题分析

问题背景

在 QuickJS-NG JavaScript 引擎中，开发者报告了一个关于大整数(BigInt)转换为字符串时出现的异常问题。该问题仅在 Clang 20 编译器环境下出现，而在 Clang 19 中则表现正常。具体表现为当处理超出 64 位有符号整数范围的大整数时，会出现内存访问异常或"内存不足"的 JavaScript 异常。

问题复现

通过一个精简的 C 语言测试用例可以稳定复现该问题。测试代码创建了一个 JavaScript 运行时环境，并尝试将字符串"-9223372036854775808n"(刚好超出 64 位有符号整数最小值的 BigInt)转换为 16 进制字符串表示。在 Clang 20 编译环境下，这个操作会随机导致指针异常或 JavaScript 的"内存不足"异常。

技术分析

经过深入分析，发现问题根源在于 QuickJS-NG 的 js_bigint_to_string1 函数实现。该函数在处理大整数转换为字符串时，没有正确处理某些边界情况，特别是当数值为零或特定负值时。在 Clang 20 更严格的优化和代码生成策略下，这种未定义行为被暴露出来。

解决方案

QuickJS-NG 项目维护者提出了两种解决方案：

1. 全局性修复：修改底层的大整数处理逻辑，确保在所有情况下都能正确处理零值和边界条件。这种方法更为全面，可以预防类似问题在其他地方出现。

2. 局部修复：仅在出现问题的调用点添加特殊处理。虽然能解决当前问题，但可能不是最彻底的解决方案。

最终项目采用了第一种全局性修复方案，通过修改底层的大整数处理逻辑来从根本上解决问题。这种修改确保了代码在不同编译器版本和优化级别下的稳定性。

经验总结

这个案例给开发者带来几点重要启示：

1. 编译器版本升级可能暴露隐藏的代码问题，特别是涉及数值边界处理时。

2. 对于底层数值操作，必须严格处理所有可能的边界条件，包括零值和极值。

3. 全局性解决方案通常比局部修补更可靠，能预防类似问题在其他场景出现。

4. 跨编译器版本的测试对于保证代码稳定性非常重要。

这个问题也展示了 QuickJS-NG 项目对代码质量的重视，以及维护者快速响应和解决问题的效率，这对于一个 JavaScript 引擎项目至关重要。