编写 Windbg 扩展(使用 DbgEng.h)时,可以使用
_In_opt_ PCSTR args
接受来自 Windbg 命令行的参数;但是,这是作为完整字符串传递的。
示例:
HRESULT CALLBACK doStuff(_In_ PDEBUG_CLIENT4 Client, _In_opt_ PCSTR args)
这意味着/推断像
getopt()
这样的东西不是获取参数的可行路径,因为它们不是在 Windbg 初始化时传递的 - 而是在 Windbg 内的命令执行时传递的。
经过几周的研究,我找到了这个代码块(纯 C 语言),它将评估 PCSTR 是否包含我们想要从命令参数中获得的预期值(向 Ryan Ries 致敬)对于它)。对我来说,唯一的问题是(似乎)无法评估预期的字符串是否位于“正确的位置”。
因此,例如,如果我想允许
-q -s someModule!someMethod
,那么 Ryan 示例中的验证将适用于 -q someModule!someMethod -s
;这本质上不是一个问题,但我想在调试器扩展中继续处理之前验证输入是否符合预期(参数和值位于正确的位置)。
我怀疑在空格字符上分割字符串可能是可行的方法,但我想知道这是否是对作为
args
传入的 PCSTR
进行输入验证的推荐/首选方法,因为这样我们就必须假设索引可能不一定是真的。因此,例如,-q -s someModule!someMethod
的最后一个索引与 -s someModule!someMethod
不同。
是否有标准/首选/“正确”的方法来评估通过
PCSTR
传入的参数?如果是这样,我找不到任何可以使用的示例或“最佳实践”。
如果没有,处理未提供的 some 参数的条件并尝试索引
someModule!someMethod
的位置的“最佳方法”是什么?
这些样本是仅来自SDK吗?
probably yes I have not checked or used the store package
我这里有
C:\>dir /s /b "c:\Program Files (x86)\Windows Kits\10\Debuggers\inc\*.cpp"
c:\Program Files (x86)\Windows Kits\10\Debuggers\inc\engextcpp.cpp
相关部分如下
C:\>pss Parse "c:\Program Files (x86)\Windows Kits\10\Debuggers\inc\engextcpp.cpp"
c:\Program Files (x86)\Windows Kits\10\Debuggers\inc\engextcpp.cpp
259:ExtCommandDesc::ParseDirective(_In_ PSTR Scan)
354:ExtCommandDesc::ParseArgDesc(void)
357: // Parse the argument description.
397: Scan = ParseDirective(++Scan);
809: ParseArgDesc();
2436: ParseArgs(Desc, Args);
3004:ExtExtension::ParseArgs(_In_ ExtCommandDesc* Desc,
记录在这里