g++ 13.2中std::format_to_n的实现是否存在Bug？

先直接给结论：你观察到的现象确实是g++ 13.2的libstdc++标准库实现中的一个bug，这个问题在后续的g++ 13.3、14.x及更高版本中已经被修复了。

先看你的测试代码（已格式化）：

// #define USE_FMTLIB
#include <chrono>
#include <iostream>

#if defined(USE_FMTLIB)
#include <fmt/chrono.h>
#include <fmt/core.h>
#else
#include <format>
#endif

int main() {
    constexpr std::size_t STATIC_BUFF_SIZE = 1024;
    static char static_buff[STATIC_BUFF_SIZE];
    const auto timepoint = std::chrono::system_clock::now();

    const auto prefix_format_result =
#if defined(USE_FMTLIB)
    fmt::format_to_n(
#else
    std::format_to_n(
#endif
        static_buff, STATIC_BUFF_SIZE, "timestamp:{:%Y-%m-%d %H:%M:%S}", timepoint
    );

    std::cout << (prefix_format_result.out - static_buff) << "\n";
}

编译参数：-std=c++20 -O3 -Wall -Wextra -pedantic -pedantic-errors

现象背后的原因 #

当启用USE_FMTLIB时，fmt库的format_to_n实现是正确的：它会把out指针指向格式化内容的末尾（即static_buff + 39），所以你通过out - static_buff计算出的实际写入字符数是39，符合预期。

而在g++ 13.2中禁用USE_FMTLIB时，标准库的std::format_to_n出现了异常行为：它错误地将out设置到了缓冲区的末尾（static_buff + 1024），导致你计算出的结果是1024——但实际上格式化后的内容仅需39个字符，1024大小的缓冲区完全足够容纳。后续的g++版本修复了这个逻辑错误，所以能正确返回39。

关于format_to_n返回值中size与out的疑问 #

你提到的“两者是否重复”是个很常见的误解，实际上它们的语义在缓冲区空间不足的场景下有本质区别：

• size：代表格式化完整内容所需的总字符数，和缓冲区容量无关。如果内容能完全放入缓冲区，size等于实际写入的字符数；如果缓冲区不够，size会是完整内容的长度（大于缓冲区容量），帮你判断需要多大的缓冲区才能装下完整内容。
• out：指向缓冲区中最后一个写入字符的下一个位置。如果内容能完全放入，out - 起始指针等于size；如果缓冲区不足，out会停在缓冲区的末尾（即起始指针+缓冲区容量），此时out - 起始指针等于缓冲区大小，代表缓冲区已被写满。

举个直观的例子：如果你的缓冲区只有20个字符，而格式化完整内容需要39个字符，那么：

• size会返回39（告诉你完整内容的真实长度）
• out会指向static_buff + 20（告诉你缓冲区已经写满）

这时候两者的数值就完全不同了——这也是标准同时提供这两个值的核心原因，让你既能知道实际写入的字符数，也能知道完整内容的需求长度。

内容来源于stack exchange