QuickJS项目在Windows SDK 26100下的兼容性问题分析

背景介绍

QuickJS是一个轻量级的JavaScript引擎，最近在Windows平台开发时遇到了一个与Windows SDK 26100版本相关的兼容性问题。这个问题源于Windows SDK对NAN宏定义的修改，导致QuickJS在编译时出现错误。

问题本质

在Windows SDK 22621及更早版本中，NAN宏被定义为：

#define NAN ((float)(INFINITY * 0.0F))

而在Windows SDK 26100中，微软修改了NAN的定义方式：

#define _UCRT_NAN (__ucrt_int_to_float(0x7FC00000))
#define NAN _UCRT_NAN

这种改变导致使用SDK 26100时，编译器（无论是msvc-cl 19.41还是clang-cl 19.1）会报告错误："C2099 initializer is not a constant"，因为新的定义方式不再产生编译期常量。

技术影响

这个问题对QuickJS的影响主要体现在以下几个方面：

1. 编译失败：直接导致项目无法在Windows SDK 26100环境下编译通过
2. 序列化一致性：QuickJS的libbf模块和JS_WriteObject序列化器依赖于特定的NAN值，不同的NAN定义可能导致不同机器产生不同的输出

解决方案探讨

目前有几种可能的解决方案：

1. 定义_UCRT_NOISY_NAN宏：可以恢复22621之前的行为，但需要注意：

   • 在/fp:precise模式下，22621会产生负NAN
   • 在/fp:strict模式下，22621会产生正NAN
   • 26100在定义_UCRT_NOISY_NAN后会产生负NAN

2. 代码重构：修改QuickJS代码，使其不依赖NAN作为编译期常量

3. 使用特定工具链：如MinGW可能自带NAN定义，可以绕过这个问题

实际测试结果

测试显示，在不同条件下NAN的值表现如下：

• 默认/fp:precise模式：

  • SDK 22621: fff8000000000000（负NAN）
  • SDK 26100: 7ff8000000000000（正NAN）
  • 定义_UCRT_NOISY_NAN后：fff8000000000000（负NAN）

• /fp:strict模式：

  • SDK 22621和26100（定义_UCRT_NOISY_NAN）都会产生正NAN

建议方案

对于需要快速解决问题的开发者，可以考虑以下方案：

1. 在CMake配置中添加_UCRT_NOISY_NAN宏定义
2. 暂时使用Windows SDK 22621版本进行开发
3. 等待QuickJS官方对代码进行适配更新

总结

Windows SDK 26100对NAN定义的修改确实给QuickJS带来了兼容性问题。这个问题不仅影响编译过程，还可能影响运行时行为。开发者需要根据自身需求选择合适的解决方案，同时关注QuickJS官方的后续更新。

对于项目维护者来说，长期解决方案可能是重构相关代码，使其不依赖特定的NAN实现方式，从而提高跨平台兼容性。