hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								40m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 1. Держим оборонуClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

значение.1 Обычно вывод таких предупреждений можно избиратель% но включать или отключать.

Если ваш код изобилует опасными конструкциями, такие предупреж% дения могут занять многие страницы. К сожалению, по этой причине очень часто отключают вывод предупреждений компилятором или просто не обращают на них внимания. Так поступать не следует.

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

Предупреждения компилятора помогают выявить массу глупых ошибок. Все& гда включайте их вывод. Добейтесь того, чтобы ваш код компилировался молча.

Пользуйтесь средствами статического анализа

Предупреждения компилятора представляют собой результат частич% ного статического анализа кода – контроля кода, проводимого перед запуском программы.

Существует ряд самостоятельных инструментов статического анали% за, например lint или его более современные потомки для C и FxCop для сборок .NET. Вашей постоянной практикой должна стать провер% ка своего кода с помощью этих средств. Они обнаруживают гораздо больше ошибок, чем компилятор.

Применяйте безопасные структуры данных

Или, если это невозможно, пользуйтесь опасными структурами, но с осторожностью.

Вероятно, самым распространенным видом уязвимостей в программах является переполнение буфера. Оно возникает из%за небрежного при% менения структур данных фиксированного размера. Если ваш код за% писывает данные в буфер, не проверив предварительно его размер, то возникает опасность записи за концом буфера.

Это происходит с чрезвычайной легкостью, как демонстрирует сле% дующий фрагмент кода C++:

char *unsafe_copy(const char *source)

{

char *buffer = new char[10];

1Во многих языках (например, Java и C#) это считается ошибкой.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Технологииm		защитного программирования
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

strcpy(buffer, source); return buffer;

}

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
41Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Если в источнике (source) больше 10 символов, то их копирование вый% дет за пределы памяти, выделенной под буфер (buffer). Результат мо% жет оказаться самым неожиданным. В лучшем случае произойдет раз% рушение данных, если окажется измененным содержимое какой%то другой структуры данных. В худшем – злоумышленник может вос% пользоваться этой ошибкой в программе и поместить в стек програм% мы исполняемый код, с помощью которого запустит собственную про% грамму и фактически завладеет компьютером. Ошибками такого рода систематически пользуются взломщики; это серьезная проблема.

Предотвратить появление таких уязвимостей нетрудно. Не пишите скверный код! Пользуйтесь более надежными структурами данных, которые не позволяют искажать программу, например управляемыми буферами типа класса string в C++. Либо применяйте к небезопасным типам данных только безопасные операции. Приведенный выше код C++ можно защитить, заменив strcpy на strncpy, которая копирует строку ограниченной длины:

char *safer_copy(const char *source)

{

char *buffer = new char[10]; strncpy(buffer, source, 10); return buffer;

}

Проверяйте все возвращаемые значения

Если функция возвращает значение, то делает это не зря. Проверяйте возвращаемое значение. Если это код ошибки, нужно ее обработать. Не допускайте появления в программе незамеченных ошибок; в итоге поведение программы может стать непредсказуемым.

Это относится как к определенным пользователям, так и к библиотеч% ным функциям. Чаще всего коварные ошибки возникают тогда, когда программист не проверяет возвращаемые значения. Не забывайте, что иногда функции сообщают об ошибках с помощью иного механизма (например, при помощи стандартной переменной errno библиотеки C). Всегда перехватывайте и обрабатывайте соответствующие исключе% ния на соответствующем уровне.

Аккуратно обращайтесь с памятью (и другими ценными ресурсами)

Будьте скрупулезны и освобождайте все ресурсы, которые захватывае% те во время выполнения. Чаще всего имеется в виду оперативная па% мять, но это не единственный ресурс. К другим видам ценных ресурсов,

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								42m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 1. Держим оборонуClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

которые нужно беречь, относятся файлы и блокировки потоков. Рас% поряжайтесь своим добром экономно.

Не пренебрегайте тем, чтобы самостоятельно закрыть файлы или осво% бодить память, не рассчитывая, что это сделает ОС по завершении про% граммы. Неизвестно, сколь долго еще будет выполняться ваш код, по% жирая дескрипторы файлов и память. Нельзя даже быть уверенным, что ОС правильно освободит ваши ресурсы – не все системы делают это.

Существует мнение, что не стоит заниматься освобождением памяти, пока вы не убедитесь, что программа работает. Не верьте этому. Это крайне опасная практика. Она приводит к многочисленным ошибкам работы с памятью; вы обязательно пропустите какие%то места, где нужно освободить память.

Берегите все ограниченные ресурсы. Тщательно организуйте их захват и осво& бождение.

В Java и .NET есть сборщик мусора, который сделает вместо вас всю эту скучную приборку, чтобы вы могли «забыть» об освобождении ре% сурсов. Можно мусорить на пол, потому что на этапе исполнения за ва% ми будут периодически подметать. Это замечательно удобно, но у вас не должно возникнуть ложного чувства безопасности. Думать самому все равно нужно. Вы должны явно уничтожить ссылки на объекты, которые вам больше не нужны, иначе они не будут убраны; не делайте ошибки, сохраняя ссылки на объекты. Кроме того, менее изощренные сборщики мусора могут быть введены в заблуждение циклическими ссылками (например, A ссылается на B, B ссылается на A, но тот и дру% гой никому не нужны). В этом случае объекты могут никогда не по% пасть в мусор, что ведет к скрытой утечке памяти.

Инициализируйте все переменные там, где вы их объявили

Это проблема ясности. Смысл каждой переменной становится ясен, ес% ли вы инициализируете ее. Опасно полагаться на эмпирические пра% вила типа: «Раз я ее не инициализировал, значит, ее начальное значе# ние мне неважно». Код со временем развивается. Отсутствие началь% ного значения на каком%то этапе может превратиться в проблему.

C и C++ усугубляют эту проблему. Пользуясь неинициализированной переменной, вы можете получать разные результаты при каждом за% пуске программы в зависимости от мусора, находящегося в памяти. Когда вы объявляете переменную в одном месте, присваиваете ей зна% чение в другом, а пользуетесь в третьем, это открывает широкий путь для возникновения ошибок. Если не выполнить присваивание началь% ного значения, то можно потратить уйму времени, пытаясь понять причину случайного поведения программы. Закройте этот источник ошибок путем инициализации каждой переменной при ее объявле% нии. Даже если присваивается неверное значение, программа все рав% но будет вести себя предсказуемым образом.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Технологииm		защитного программирования
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
43Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Более защищенные языки (такие как Java и C#) обходят эту опасность путем определения начальных значений для всех переменных. Тем не менее полезно инициализировать переменные при их объявлении, так как это облегчает понимание кода.

Объявляйте переменные как можно позже

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

Не пользуйтесь повторно одной и той же временной переменной в раз% ных местах, даже если они логически независимы. В противном случае вы чрезвычайно осложните дальнейшую модернизацию кода. Каждый раз создавайте новую переменную, а компилятор сам разберется, мож% но ли оптимизировать такой код.

Пользуйтесь стандартными средствами языка

C и C++ в этом отношении представляют собой кошмар. Их специфи% кации существуют во многих вариантах, а поведение в наименее ясных ситуациях не определено и оставлено на усмотрение конкретных реа% лизаций. На сегодняшний день существует множество компиляторов, обладающих тонкими различиями. В целом они совместимы между со% бой, но оставляют вам достаточно возможностей свернуть себе шею.

Четко определите, какой версией языка вы пользуетесь. Если только ваш проект не оставляет иного выбора (и причины должны быть доста% точно вескими), не пользуйтесь индивидуальными особенностями ком% пилятора и нестандартными расширениями языка. Если в языке есть неопределенная область, не полагайтесь на то, как ведет себя в ней ваш конкретный компилятор (например, если ваш компилятор C рассмат% ривает char как величину со знаком, то другие компиляторы могут не делать этого). В противном случае код становится очень неустойчи% вым. А если вы перейдете на новую версию компилятора? А если в ко% манде появится новый программист, не знакомый с вашими расшире% ниями? Полагаясь на необычные свойства конкретного компилятора, вы создаете источник труднообнаруживаемых ошибок, которые мо% гут появиться в будущем.

Пользуйтесь хорошими средствами регистрации диагностических сообщений

Когда пишут новый код, то часто включают в него много операторов вывода диагностики, чтобы разобраться в происходящем в программе. Следует ли удалить их в конце работы? Сохранив их, вы облегчите