terrafx / terrafx.interop.windows

Interop bindings for Windows.
MIT License
260 stars 31 forks source link

Add missing `UNDNAME_` flags #351

Closed DaZombieKiller closed 1 year ago

DaZombieKiller commented 1 year ago

This PR adds the following new constants to um/DbgHelp/Windows.Manual.cs:

As far as I am aware, these are not present in any public headers. However, they are documented in at least two places:

Usage: undname [flags] fname [fname...] or: undname [flags] file

where flags are the following OR'd together:

0x0001 Remove leading underscores from Microsoft extended keywords 0x0002 Disable expansion of Microsoft extended keywords 0x0004 Disable expansion of return type for primary declaration 0x0008 Disable expansion of the declaration model 0x0010 Disable expansion of the declaration language specifier 0x0060 Disable all modifiers on the 'this' type 0x0080 Disable expansion of access specifiers for members 0x0100 Disable expansion of 'throw-signatures' for functions and pointers to functions 0x0200 Disable expansion of 'static' or 'virtual'ness of members 0x0400 Disable expansion of Microsoft model for UDT returns 0x0800 Undecorate 32-bit decorated names 0x1000 Crack only the name for primary declaration return just [scope::]name. Does expand template params 0x2000 Input is just a type encoding; compose an abstract declarator 0x8000 Disable enum/class/struct/union prefix 0x20000 Disable expansion of __ptr64 keyword


I have used the descriptions from the `IDiaSymbol::get_undecoratedNameEx` documentation page for the XML documentation comments.

Additionally, here are some notes describing some oddities that these constants reveal about the `UNDNAME_` flag set:

* `UNDNAME_TYPE_ONLY` shares its value with `UNDNAME_NO_ARGUMENTS` which **does** exist in the headers, despite not representing the current behavior of the flag (unlike the former).
* `UNDNAME_RESERVED1` and `UNDNAME_RESERVED2` share their values with `UNDNAME_NO_MS_THISTYPE` and `UNDNAME_NO_CV_THISTYPE` respectively. I am not sure which of the two sets of names represent today's behavior, but it is interesting that `undname.exe` does not describe the meaning of either.
* `UNDNAME_NO_SPECIAL_SYMS` shares its value with `UNDNAME_HAVE_PARAMETERS`. No description is given for it by `undname.exe` and I have not determined which name is more accurate.

Maybe it would be worth opening an issue to have the C++ documentation updated to address these ambiguities?