В тех случаях, когда внутренняя логика системы нуждается в подкреплении, X/Open предоставляет макрос assert, применяемый для проверки правильности исходных данных и остановки выполнения программы в противном случае.
<b>#include <assert.h></b>
<b>void assert(int expression)</b>
Макрос assert вычисляет выражение и, если оно не равно нулю, выводит некоторую диагностическую информацию о стандартной ошибке и вызывает функцию abort для завершения программы.
Заголовочный файл assert.h определяет макросы в зависимости от определения флага NDEBUG. Если NDEBUG определен во время обработки заголовочного файла, assert определяется по существу как ничто. Это означает, что вы можете отключить проверки заданных выражений во время компиляции, компилируя с опцией -DNDEBUG или вставив перед включением файла assert.h строку
#define NDEBUG
в каждый исходный файл.
Этот метод применения порождает проблему. Если вы используете assert во время тестирования, но отключите макрос в рабочем коде, в вашем рабочем коде может оказаться менее строгая проверка, чем применявшаяся в процессе его тестирования. Обычно макросы assert не оставляют включенными в рабочем коде — вряд ли вам понравится рабочий код, предоставляющий пользователю недружелюбное сообщение assert failed и останавливающий программу. Быть может, лучше написать свою отслеживающую ошибки подпрограмму, которая проверяет выражение, использовавшееся в макросе, но не нуждается в полном отключении в рабочем коде.
Вы также должны убедиться в том, что у выражения макроса assert нет побочных эффектов. Например, если вы применяете вызов функции с побочным эффектом, этот побочный эффект не проявится в рабочем коде с отключенными макросами assert.
Выполните упражнение 10.2.
Упражнение 10.2. Программа assert.c.
Далее приведена программа assert.c, определяющая функцию, которая должна принимать положительное значение. Она защищает от ввода некорректного аргумента благодаря применению макроса assert.
После включения заголовочного файла assert.h и функции "квадратный корень", проверяющей положительное значение параметра, вы можете писать функцию main.
#include <stdio.h>
#include <math.h>
#include <assert.h>
#include <stdlib.h>
double my_sqrt(double x) {
assert(x >= 0.0);
return sqrt(x);
}
int main() {
printf("sqrt +2 = %gn", my_sqrt(2.0));
printf("sqrt -2 = %gn", my_sqrt(-2.0));
exit(0);
}
Теперь при выполнении программы вы увидите нарушение в макросе assert при передаче некорректного значения. Точный формат сообщения о нарушении условия макроса assert в разных системах разный.
$ <b>сс -о assert assert.с -lm</b>
$ <b>./assert</b>
sqrt +2 = 1.41421
assert: assert.c:7: my_sqrt: Assertion 'x >= 0.0' failed.
Aborted
$
Как это работает
Когда вы попытаетесь вызвать функцию my_sqrt с отрицательным числом, макрос assert даст сбой. Он предоставляет файл и номер строки, в которой нарушено условие и само нарушенное условие. Программа завершается прерыванием abort. Это результат вызова abort макросом assert.
Если вы перекомпилируете программу с опцией -DNDEBUG, макрос assert не компилируется, и вы получаете NaN (Not a Number, не число) — значение, указывающее на неверный результат при вызове функции sqrt из функции my_sqrt.
$ <b>cc -о assert -DNDEBUG assert.с -lm</b>
$ <b>./assert</b>
sqrt +2 = 1.41421
sqrt -2 = nan
$
Некоторые более старые версии математической библиотеки генерируют исключение для математической ошибки, и ваша программа будет остановлена с сообщением "Floating point exception" ("Исключение для числа с плавающей точкой") вместо возврата NaN.
Устранение ошибок использования памяти
Распределение динамической памяти — богатый источник ошибок, которые трудно выявить. Если вы пишете программу, применяющую функции malloc и free для распределения памяти, важно внимательно следить за блоками, которые вы выделяете, и быть уверенным в том, что не используется блок, который вы уже освободили.
Обычно блоки памяти выделяются функцией malloc и присваиваются переменным-указателям. Если переменная-указатель изменяется, и нет других указателей, указывающих на блок памяти, он становится недоступным. Это утечка памяти, вызывающая увеличение размера программы. Если вы потеряете большой объем памяти, скорость работы вашей системы, в конце концов, снизится, и система уйдет за пределы памяти.
Если вы записываете в область, расположенную после конца выделенного блока (или перед началом блока), вы с большой долей вероятности повредите структуры данных, используемые библиотекой malloc, следящей за распределением памяти. В этом случае в какой-то момент времени вызов malloc или даже free приведет к нарушению сегментации, и ваша программа завершится аварийно. Определение точного места возникновения сбоя может оказаться очень трудной задачей, поскольку нарушение могло возникнуть задолго до события, вызвавшего аварийное завершение программы.
Неудивительно, что существуют коммерческие и бесплатные средства, способные помочь в решении проблем этих двух типов. Например, есть много разных версий функций malloc и free, которые содержат дополнительный код для проверки выделения и освобождения блоков памяти и пытаются учесть двойное освобождение блока и другие типы неправильного использования памяти.