【问题标题】:SetNamedSecurityInfo takes a writeable path; how big should the buffer be?SetNamedSecurityInfo 采用可写路径;缓冲区应该有多大?
【发布时间】:2019-08-29 20:34:32
【问题描述】:

SetNamedSecurityInfo 被定义为采用 LPTSTR,而不是 LPCTSTR。现在,采用LPTSTR 的标准 Win32 API 也有一些方法可以指示必要的缓冲区长度。有时这在签名中是明确的,有时它被记录为MAX_PATH 或其他。 SetNamedSecurityInfo 并非如此。

老实说,我不知道SetNamedSecurityInfo 为什么要写入 到该缓冲区,但也许它会尝试就地规范化路径。但那我可能需要支持 32768 个字符?

【问题讨论】:

  • 我猜他们只是打错了类型,应该是 const。
  • 在形式上,当然,这不能被证明(什么被认为是证据?)但是 name 可以指向恒定的只读内存。这个 api 从不尝试修改名称 - 实际上这并不需要。在打开对象句柄之前,名称需要从 win32 格式转换为本机格式,但这无论如何都无法就地完成 - 始终为最终本机路径分配新缓冲区。这里没有像CreateProcessW 这样的情况,当 api 临时想在 cmdline 中写入 0,如果未提供应用程序名称
  • 文档说它被识别为一个以空字符结尾的字符串。

标签: winapi path constants


【解决方案1】:

如您在文档中看到的SetNamedSecurityInfo

pObjectName

指向以空结尾的字符串的指针,它指定了 为其设置安全信息的对象。

这意味着将发送到函数中的缓冲区长度始终与缓冲区的字符串长度相关。

【讨论】:

  • 那个 null 是调用者 you 放置字符串输入结尾的位置。但是参数是非常量的,它显然是被调用者修改的。但是怎么做呢?
  • 文档中没有说明调用者会修改它的值,即使你在函数中传递了LPTSTR类型的值,你也不一定要在里面修改它的值.与定义为LPCSTR相比,不够严谨。
猜你喜欢
  • 2012-11-29
  • 2019-12-25
  • 2016-02-12
  • 1970-01-01
  • 2010-10-13
  • 1970-01-01
  • 1970-01-01
  • 2011-02-21
  • 2021-02-25
相关资源
最近更新 更多