关于std::filesystem::path::wstring()是否会修改errno的技术问询

好问题！这确实是C++里调用依赖errno的系统函数时，很容易踩的细节坑，我来给你把这个问题讲透：

首先从C++标准的硬性规定来说：C++17及后续版本中，std::filesystem::path的所有字符串转换成员函数（包括wstring()），标准明确要求它们不得修改errno。

为什么这么说？因为标准对这些函数的错误处理规则是：如果转换过程中出现错误（比如编码不兼容、无法把原生路径编码转换为宽字符编码），函数会直接抛出std::filesystem::filesystem_error异常，而不是通过设置errno来报告错误。标准里没有给这些函数留下任何可以修改errno的空间。

再结合你提到的Linux场景：Linux下std::filesystem::path::wstring()会把原生的UTF-8路径转换为宽字符字符串，这个过程确实涉及内存分配，但C++标准里的默认内存分配器（new操作符）也不会修改errno——只有当你自定义了会设置errno的分配器时才可能出现例外，但这属于非常见的特殊情况。

不过这里还是给你一个更稳妥的编码建议：如果你担心某些非标准的编译器实现可能有疏漏，或者未来的代码变更引入风险，完全可以先把errno的值保存下来，再调用wstring()，代码示例如下：

int fd = open(fileName.c_str(), O_RDONLY);
if (fd < 0) {
    // 先保存errno，彻底规避参数求值顺序的问题
    int saved_err = errno;
    std::wstring fname_str = fileName.wstring();
    reportError(saved_err, fname_str);
}

这种写法完全消除了参数求值顺序带来的不确定性，不管wstring()的行为如何，都能保证传给reportError的是open调用失败时的正确错误码。

内容来源于stack exchange