Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ну и что ? Это лишь говорит о том, что они неверно оценили максимальный размер, только и всего.

PD>Вот давай так

PD>char szTotal[500];
PD>sprintf(szTotal,"%s %s", szFirstName, szLastName);

PD>Программа делается для России. Приведи ситуацию, в которой здесь возможен buffer overrun. Фамилию и имя, please , в студию.
Очень просто. Этот код вызывается из обработчика веб формы регистрации пользователей. Злонамеренный пользователь вводит килобайт мусора. После чего твое CGI приложение делает core dump. Это называется уязвимость.
Еще более злонамеренный пользователь вводит килобайт специального мусора, и твое CGI приложение вносит нужные изменения в системные настройки, а уже потом делает core dump. Это называется эксплойт.
Продвинутый злонамеренный пользователь пишет плагин к известному сканеру сетей, который находит все инстансы твоего приложения в указанном IP — диапазоне.
Таоя компания попадает в списки рассылки "смертельно опасные уязвимости", и ее продукт попадает в черный список. Это называется "банкротство".

Дальше продолжать?
В таком сценарии оказывается значительно дешевле вовремя уволить того, кто использует подобный код, чем любая из альтернатив:
— оплачивать расходы от невовремя обнаруженной уязвимости
— нанять специальных людей, которые станут тестировать твою систему на предмет наличия подобных уязвимостей.
PD>Ну и что, опять-таки ? См. мой пример с nScreenArea. Может, оно когда-нибудь и грохнется, на 4ГПикс дисплее.
Еще раз: то, как оно грохнется от целого переполнения, не приведет к исполнению постороннего кода.
PD>Но не будешь же ставить под контроль все арифметические операции и на каждую из них писать try-catch из-за того, что при некорректно заданных операндах это может вызвать ошибку ?
Будешь, если тебе дорого твое место работы. Причем кэтчить все места тебе не потребуется: как только придет информация о том, что где-то твое приложение упало, ты получишь нормальный стек трейс, в котором ясно будет указано место падения.
Это позволит тебе очень быстро (по сравнению с анализом дампа) локализовать причины, и либо переписать код (например, используя long вместо int), либо вставить в нужных местах проверки (например там, где принимаются размеры).
PD>Если да — то неудивительно, что это будет работать очень медленно. А если нет — то при работе однажды произойдет unhandled exception, и аппарат рухнет.
PD>Нет. Не догадываюсь. Потому что любая ошибка может привести к любой наведенной ошибке. А если ты хочешь сказать, что при этом будет неопределенное поведение — так и при неправильных результатах будет то же, не только при выходе индекса.
Нет. Выброс исключения — это НЕ непределенное поведение. Это вполне определенное поведение, которое

PD>А вообще основное различие между моей и твоей позицией ИМХО в том, что ты хорошо знаешь некоторые общепринятые принципы, но рассматриваешь их как догму, которую нельзя переступать, как сказал Sinclair, под страхом смертной казни. Я же считаю, что при определенных условиях может случиться так, что делать придется, нарушая многие общепринятые правила, если это нужно для решения задачи и другого выхода нет. В конце концов лучше написать работающую программу не по правилам, чем по правилам ничего не сделать.
Ты не прав. Если влезть в исходники .Net, то можно увидеть и unsafe, и unchecked. Как раз для того, чтобы поднять производительность. Это не переступание догм, это подробное следование им. Потому, что отмененные такими опциями проверки делаются вручную. Сделать правильную программу быстрой легче, чем быструю — правильной.

Потому, что обо всех небыстростях тебе расскажет профайлер, а о неправильностях — пользователи и хакеры.