C++检测glibc版本时浮点数转换丢失小数部分问题排查

问题出在区域设置（locale）对数值解析规则的影响：

• gnu_get_libc_version()返回的版本字符串固定使用.作为主次版本分隔符，不受程序运行时的区域设置影响
• std::stod、默认配置的boost::lexical_cast<double>做字符串转浮点数时，会使用当前程序的全局区域设置识别小数点：
  • 英文类区域设置（如en_US.UTF-8）中，小数点符号为.，可以正常解析2.34得到正确的浮点数值
  • 法、德等欧陆区域设置（如fr_FR.UTF-8、de_DE.UTF-8）中，小数点符号为逗号,，解析函数遇到字符串里的.时会判定为无效字符，直接终止解析，仅转换.前的整数部分，最终得到数值2，这就是小数部分丢失的直接原因
    你在自有设备上无法复现，是因为你的测试环境默认使用小数点为.的区域设置，切换到fr_FR.UTF-8这类区域后触发问题，和这个逻辑完全吻合。

版本号本质是分段的整数组合，用浮点数存储本身就存在设计缺陷，除了locale问题外还存在潜在的浮点数精度风险，以下两种方案都可以彻底解决问题：

方案1：最小改动，强制使用C经典locale做解析 #

如果你暂时不想改动浮点数比较的逻辑，可以直接绕过依赖全局locale的解析接口，使用固定按.识别小数点的C标准库函数做转换：

#include <cstdlib>
#include <string>

double get_glibc_version_num() {
    const char* ver_cstr = gnu_get_libc_version();
    char* parse_end = nullptr;
    // strtod默认使用"C"区域规则，按`.`识别小数点，不受用户locale影响
    double ver = std::strtod(ver_cstr, &parse_end);
    return ver;
}

不要通过临时修改全局locale的方式适配std::stod，这种方式在多线程场景下存在线程安全问题，可能导致其他线程的数值解析逻辑出现异常。

方案2：拆分主次版本为整数比较（长期最稳妥） #

用浮点数存储版本号的设计存在天然缺陷（比如未来出现2.100版本时，浮点数精度可能导致比较逻辑出错），最可靠的实现是拆分主、次版本号为整数后再比较：

#include <cstdlib>

bool should_run_new_binary() {
    const char* ver_cstr = gnu_get_libc_version();
    char* parse_end = nullptr;
    // 解析主版本号
    long major_ver = std::strtol(ver_cstr, &parse_end, 10);
    if (major_ver > 2) {
        return true;
    }
    if (major_ver < 2) {
        return false;
    }
    // 跳过点号解析次版本号
    if (*parse_end == '.') {
        parse_end++;
    }
    long minor_ver = std::strtol(parse_end, nullptr, 10);
    return minor_ver >= 34;
}

这个实现完全不依赖区域设置规则，也不存在浮点数精度问题，适配所有未来的glibc版本。

关于boost::lexical_cast的补充 #

默认构造的boost::lexical_cast会使用全局locale做解析，因此会出现和std::stod完全一致的问题。如果一定要用这个接口，需要手动传入使用"C" locale的转换facet，改动成本远高于上面两种方案，不推荐。

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