函数 PathCombine() 和 PathCchCombine() 的替代方法答案

【问题标题】：alternatives to functions PathCombine() and PathCchCombine()函数 PathCombine() 和 PathCchCombine() 的替代方法
【发布时间】：2019-05-02 18:23:02
【问题描述】：

我正在为 Windows 7 和 Windows 10 编写代码，并且希望我的应用程序只有一个主二进制文件。

在这个应用程序中，我想加入一个路径和一个文件名，以便消除所有相对路径规范。现在我发现当使用 PathCombine() 函数时，我是可移植的，但函数本身有机会在某些输入条件下创建缓冲区溢出问题。对于 PathCchCombine()，通过提供结果缓冲区大小的额外参数提高了安全性，但它在第一个提到的平台上不可用（该功能仅在 Win8 或更高版本上提供 - 可能与 api-ms-win-core-path- 一起提供l1-1-0.dll 或仅由 Windows KernelBase.dll）。

如何解决这个问题，这样我就可以保留一个二进制文件，不需要提供额外的 DLL 并且仍然保持保存以防止缓冲区溢出？是否有一些适用于我的 Windows 7 替代功能？

【问题讨论】：

PathCombine 没有表现出缓冲区溢出的可能性“按设计”。它仅在 “误用” 时通过提供太小的输出缓冲区来显示缓冲区溢出。如果您传递足够大的输出缓冲区，则不会出现缓冲区溢出。您知道输出的最大长度（pszDir 的长度 + pszFile 的长度 + 1 用于可能添加的路径分隔符）。
我不确定输入缓冲区是否有 MAX_PATH 或更少的字符，无论是单独的还是在各种路径字符串调整后组合。 MAX_PATH 不是现实世界系统的限制。然后 Cch 函数将限制设置为定义为 0x8000 = 32 kB 的 PATHCCH_MAX_CCH。
感谢您指出文档中关于误用和设计的措辞的不同之处。实际上，如果传递的缓冲区少于 MAX_PATH 字符，我认为 MSVC 编译器不会警告我，而且在运行时我也不希望任何机制能够捕获这样的错误情况。 Cch 设计非常出色，但我有什么好的选择可以在所有提到的 Windows 版本中使用这样的 API 功能？
经过更多研究后，我觉得我跳进了一个古老但大的坑，关于许多应用程序的内置路径限制为 MAX_PATH=260 - 即使在今天也是如此。 social.msdn.microsoft.com/Forums/en-US/…
在路径上找到了这个问题，并将它们与我提到的 api 调用结合起来。答案最终出现在自己编写的代码中——还有许多关于代码提案完整性和一致性的问号。 stackoverflow.com/questions/33150102/…

标签： winapi windows-7

【解决方案1】：

指示解决方案：

我需要使用 PathCombine() 因为它是唯一适用于 Win7 的选项。

我必须提供一个 MAX_PATH 的结果缓冲区（越小有风险，越大无用）。

我必须接受，即使 Win10 可能支持 32kB 或更长的路径长度，也没有简单的解决方案（如单个 API 调用）可以处理任何平台确定的限制和/或内容确定的结果长度。 - 有一些函数变体（考虑 PathAllocCanonicalize）进行动态分配，因此调用者不需要任何预结果知识，但所有这些函数似乎只在 Win8 或更高版本中可用。

【讨论】：