深入解析cppformat项目中FMT_BUILTIN_TYPES宏对long类型格式化的影响

在cppformat（现称fmtlib）项目中，当开发者使用FMT_BUILTIN_TYPES=0宏定义时，可能会遇到一个关于long类型格式化输出的异常问题。这个问题表现为格式化输出时数值显示错误，例如预期的1234变成了一个随机数值536895556。

问题现象

当项目配置中定义了FMT_BUILTIN_TYPES=0宏时，以下代码会出现异常行为：

#define FMT_BUILTIN_TYPES 0
#include <cstdint>
#include <fmt/format.h>

int main() {
    long n(1234);
    fmt::print("1234!={}", n); // 预期输出"1234!=1234"，实际输出错误数值
}

问题根源分析

这个问题的根本原因在于fmtlib库内部类型处理逻辑的冲突。当FMT_BUILTIN_TYPES=0时，库会禁用一些内置类型的特殊处理路径，转而使用更通用的处理方式。

具体来说，问题发生在两个关键环节：

1. 类型判断阶段：库的类型判断逻辑（stored_type_constant）错误地将long类型识别为int_type，而不是预期的custom_type。

2. 值存储阶段：由于禁用了内置类型处理，long类型的值实际上是通过custom_tag路径存储的，但在后续处理时却被当作int_type来处理，导致访问了联合体(union)中的错误成员。

技术背景

在fmtlib的设计中，FMT_BUILTIN_TYPES宏控制着是否使用编译器内置的类型处理优化。当设置为0时：

• 禁用内置类型特殊处理路径
• 强制使用更通用的格式化路径
• 增加类型安全性但可能牺牲一些性能

这种设计原本是为了支持非标准类型系统（如某些嵌入式平台）而存在的，但在处理long类型时出现了逻辑问题。

解决方案

fmtlib开发团队在最新提交中修复了这个问题。修复的核心是确保当FMT_BUILTIN_TYPES=0时，long类型能够被正确地识别和处理。

修复后的行为：

1. 正确识别long类型的类型标识
2. 确保值存储和访问路径一致
3. 保持与其他类型的处理逻辑兼容

开发者建议

对于使用fmtlib的开发者，特别是那些在非标准平台上工作的开发者，建议：

1. 如果遇到类似数值格式化异常问题，首先检查FMT_BUILTIN_TYPES的设置
2. 在跨平台项目中，特别注意long类型在不同平台上的尺寸差异（32位/64位）
3. 考虑更新到最新版本的fmtlib以获取此修复
4. 在关键数值格式化代码中添加断言或测试用例

总结

这个案例展示了C++类型系统与格式化库交互时可能出现的问题，特别是在跨平台和自定义类型处理场景下。fmtlib团队通过及时修复确保了库的健壮性，同时也提醒开发者在使用类似宏定义时需要充分理解其对类型系统的影响。