Деманглинг имен в Visual C++.
На днях пытался понять, отчего и почему крошечное приложение пухнет как на дрожжах при добавлении некоторых библиотек из Boost. Рассматривая сгенерированный map файл, выяснил, что утилита undname.exe поставляется вместе с Visual Studio и в состав Windows SDK не входит. Пришлось написать свою – там всего-то нужно вызвать одну функцию (UnDecorateSymbolName). По ходу дела нашел несколько интересных ссылок по теме:
- Схема, по которой кодируются имена:
- Tips: Visual C++ – упоминает, что UnDecorateSymbolName не умеет декодировать имена классов. Вместо неё предлагается использовать недокументированную функцию, предоставляемую самим компилятором – _unDName. Вот аналогичная жалоба на rsdn.ru.
- Исходный код _unDName из проекта Wine
Разница между UnDecorateSymbolName и _unDName меня совсем не удивляет. Эти функции происходят из двух разных проектов. UnDecorateSymbolName (dbghelp.dll) – это реализация из WinDbg (Windows Division). _unDName (msvcrt.dll) пишут разработчики компилятора (DevDiv). К счастью, новые версии WinDbg выходят гораздо чаще, чем новые версии Visual C++. Есть шанс, что найденные ошибки будет оперативно подправлены. 
Немного не по теме, но, может быть, Вы поможете найти причину порчи памяти в Far’e
http://bugs.farmanager.com/view.php?id=1145 ? Проявляется только при использовании релизной версии библиотек.
@Denis
Я добавил комментарий с описанием последовательности, приводящей с порче памяти в багтрекер. Надеюсь это поможет.
PS. Код Far’а по-прежнему ужасен.
Огромное спасибо! А можете поделиться информацией, как с помощью AppVerifier удалось поймать ошибку? Спасибо.
@Denis
http://technet.microsoft.com/en-us/library/bb457063.aspx
В данном случае достаточно было собрать релизную версию с символами (привет Far Team), включить проверку кучи и воспроизвести баг. Потом нужно было сделать strStr локальной переменной, чтобы знать где именно она портится и все.