SEH, нарушение прав доступа и страница стека

Question

Я опубликовал вопрос о проверке доступности указателя. Был сделан вывод: либо использовать IsBadReadPtr для проверки указателя, либо SEH, чтобы перехватить исключение (и желательно не использовать ни то, ни другое и отладить приложение, но здесь это не проблема).

IsBadReadPtr считается плохим, потому что, в частности, он попытается прочитать указатель и перехватит любое исключение. Он может перехватить исключение страницы защиты стека и, таким образом, предотвратить доступ к диспетчеру памяти, который должен был увеличить стек.

Если я использую SEH и ловлю только исключения EXCEPTION_ ACCESS_VIOLATION, это создаст такую ​​же проблему?

Другое дело: каковы последствия использования SEH? Эта статья предполагает, что «компилятор не может выполнить анализ потока в коде, защищенном SEH». Как насчет того, чтобы вызвать функцию внутри блока __try? Разве компилятор вообще не оптимизирует вызываемую функцию?

Answer 1

Если я использую SEH и ловлю только исключения EXCEPTION_ ACCESS_VIOLATION, это создаст такую ​​же проблему?

Я думаю, что так и будет. Обходной путь может заключаться в том, чтобы исследовать стек (ы) любого потока, который вы знаете и о котором заботитесь, прежде чем начинать вызывать IsBadReadPtr (под «зондированием стека» я имею в виду намеренное касание каждой страницы памяти в стеке, чтобы гарантировать страница предварительно выделена).

Не будет ли компилятор вообще не оптимизировать вызываемую функцию?

Если функция не встроенная, я ожидаю, что компилятор будет применять обычные оптимизации (оптимизация функции не будет зависеть от того, откуда вызывается функция).