Статический анализ кода для обнаружения передачи wchar_t * в BSTR

Поскольку BSTR - это только typedef для wchar_t * , в нашей кодовой базе их несколько (много? ) места, где строковые литералы передаются методу, ожидающему BSTR , это может испортить маршаллеры или любого, кто пытается использовать какой-либо специфический метод BSTR (например, SysStringLen ).

Есть ли какой-либо способ статически обнаружить этот тип неправильного использования?

Я пытался скомпилировать с помощью VC10 / Wall и со статическим анализом кода Microsoft All Rules , но следующая оскорбительная часть кода не помечается ни одним из них.

void foo(BSTR str)  
{
    std::cout << SysStringLen(str) << std::endl; 
}

int _tmain()
{
    foo(L"Don't do that");
}

Обновление: После попытки вандализма wtypes.h для обнаружения подобных нарушений я отказался.

Я пробовал два пути, оба из которых мне приходилось работать с моим примером программы, приведенным выше, но как только я попробовал реальный проект, они потерпели неудачу.

1. создают класс с именем BSTR , но поскольку ВАРИАНТ имеет BSTR в качестве члена объединения, новый класс не может иметь никаких конструкторов или операторов присваивания в этом сломались все места, были NULL обрабатывались как BSTR . Я попытался заменить NULL типом, который имеет операторы преобразования, но после добавления десятков новых операторов (сравнение, преобразование и т. Д.)) Я начал нарваться на неоднозначные звонки и сдался.
2. Затем я попробовал способ, предложенный @CashCow и @Hans (сделав BSTR typedef на другой тип указателя). Это тоже не сработало, после добавления методов вBSTR и fromBSTR и засорения comutil.h ( _bstr_t ) и других мест с преобразованиями Наконец я дошел до того, что компилятор подавился заголовками, созданными из IDL (значения по умолчанию переводятся в буквальные широкие строки).

Короче говоря, я отказался от попыток добиться этого самостоятельно, и если кто-нибудь знает инструмент анализа кода, который может помочь, я был бы очень рад услышать об этом.