Ещё одна причина, почему не следует разбазаривать свободное место в стеке

В Microsoft, по крайней мере, в той его части, что разрабатывает Windows, весьма неплохо поставлен процесс отладки падений, сбоев и прочих багов. Автоматические тесты при падении вываливаются в отладчик. Если какая либо проблема воспроизводится локально, то обычно не нужно просить прислать crash dump или адрес сессии отладчика – так называемый remote. Словечко происходит от утилиты «remote.exe», которая идет в комплекте с «WinDbg.exe» и делает, в общем-то, тоже самое, что и Telnet, но через именованные трубы (named pipes). Не спрашивайте меня, почему нельзя было использовать тот же Telnet. Для меня это тоже загадка. Но я отклоняюсь от темы.

Так вот, постоянное использование отладочных инструментов приводит к тому, что практически любой человек, за исключением совсем уж далеких от разработки людей, умеет запустить отладчик и провести начальный анализ проблемы. Естественно не без помощи волшебной команды “!analyze –v”. Помимо всей прочей полезной информации “!analyze –v” умеет определять вероятное место сбоя по трассировке стека и по нему – вероятного владельца кода. Работает это весьма неплохо, так что владелец обычно находится быстро. Теперь представьте, что вы автор библиотечной функции, которая, например, размещает небольшой буфер в стеке:

void GreedyBastard()
{
	char buffer[0x10000];	// 64K is enough for anyone.
	…
}

Предположим также, что функция абсолютно корректна, и она действительно нуждается в буфере такого размера. Что произойдёт, если ваша функция станет достаточно популярной? Вы станете получать всё больше и больше писем о том, что ваша функция переполнила стек. Количество писем будет тем выше, чем большее число приложений использует вашу функцию. При этом поток писем почти не зависит от корректности вашей функции. Даже если из кода очевидно, что виновник переполнения находится выше по стеку. Все от того, что во время начального анализа на код почти никто не смотрит. Срабатывает триггер «мое – не мое» и если «не мое», то отчет отправляется тому, чьё имя высветила «!analyze -v». Так что рано или поздно, но код придется переписать. :-)