Linux программирование в примерах
вернуться

Роббинс Арнольд
Шрифт:

12 assert(array != NULL);

13 assert(size > 0);

14 for (i = 0; i < size; i++)

15 if (array[i] == value)

16 return i;

17

18 assert(i == size);

19

20 return -1;

21 }

22

23 /* main --- проверить наши условия */

24

25 int main(void)

26 {

27 #define NELEMS 4

28 static int array[NELEMS] = { 1, 17, 42, 91 };

29 int index;

30

31 index = lsearch(array, NELEMS, 21);

32 assert(index == -1);

33

34 index = lsearch(array, NELEMS, 17);

35 assert(index == 1);

36

37 index = lsearch(NULL, NELEMS, 10); /* won't return */

38

39 printf("index = %d\n", index);

40

41 return 0;

42 }

После компиляции и запуска оператор проверки в строке 12 «выстреливает»:

$ ch12-assert /* Запуск программы */

ch12-assert: ch12-assert.c:12: lsearch: Assertion 'array != ((void *)0)' failed.

Aborted (core dumped)

Сообщение от

assert
варьирует от системы к системе. Для GLIBC на GNU/Linux сообщение включает имя программы, имя файла с исходным кодом и номер строки, имя функции, а затем текст завершившегося неудачей условия. (В этом случае именованная константа
NULL
проявляется в виде своего макрорасширения '
((void*)0)'
.)

Сообщение '

Aborted (core dumped)
' означает, что
ch12-assert
создала файл
core
; т.е. снимок адресного пространства процесса непосредственно перед его завершением. [122] Этот файл может быть использован впоследствии с отладчиком; см. раздел 15.3 «Основы GDB». Создание файла
core
является намеренным побочным результатом
assert
; предполагается, что произошла решительная ошибка, и вы хотите исследовать процесс с помощью отладчика для ее определения.

122

Как упоминалось в разделе 10.2 «Действия сигналов», некоторые дистрибутивы GNU/Linux запрещают создание файлов

core
. Чтобы снова разрешить их, поместите в свой файл
~/.profile
строку '
ulimit -S -с unlimited
' — Примеч. автора.

Вы можете отменить оператор проверки, компилируя свою программу с помощью опции командной строки '

– DNDEBUG
'. Когда этот макрос определен до включения
<assert.h>
, макрос
assert
расширяется в код, который ничего не делает. Например:

$ gcc -DNDEBUG=1 ch12-assert.c -о ch12-assert /* Компиляция с -DNDEBUG */

$ ch12-assert /* Запуск */

Segmentation fault (core dumped) /* Что случилось? */

Здесь мы получили настоящий дамп ядра! Мы знаем, что операторы проверки были запрещены; сообщения «failed assertion» нет. Что же случилось? Рассмотрите строку 15

lsearch
при вызове из строки 37
main
. В этом случае переменная
array
равна
NULL
. Доступ к памяти через указатель
NULL
является ошибкой. (Технически различные стандарты оставляют «неопределенным» то, что происходит при разыменовывании указателя
NULL
. Наиболее современные системы делают то же, что и GNU/Linux; они завершают процесс, посылая ему сигнал
SIGSEGV
; это, в свою очередь, создает дамп ядра. Этот процесс описан в главе 10 «Сигналы».

Этот случай поднимает важный момент относительно операторов проверки. Часто программисты ошибочно используют операторы проверки вместо проверки ошибок времени исполнения. В нашем случае тест '

array != NULL
' должен был быть проверкой времени исполнения:

if (array == NULL) return -1;

Тест '

size > 0
' (строка 13) менее проблематичен; если
size
равен 0 или меньше 0, цикл никогда не исполнится, и
lsearch
(правильно) возвратит -1. (По правде, этот оператор проверки не нужен, поскольку код правильно обрабатывает случай '
size <= 0
'.)

Логика, стоящая за отменой оператора проверки, заключается в том, что дополнительные проверки могут снизить производительность программы и поэтому должны быть запрещены в заключительной версии программы. Хоар [123] , однако, сделал такое замечание:

«В конце концов, абсурдно делать тщательные проверки безопасности при отладочных запусках, когда к результатам нет никакого доверия, а затем удалять их из финальных версий, когда ошибочный результат может быть дорогим или катастрофическим. Что бы мы подумали об энтузиасте-мореплавателе, который надевает свой спасательный жилет при тренировке на сухой земле и снимает его, как только выходит в море?»

123

Hints On Programming Language Design, C.A.R. Hoare Stanford University Computer Science Technical Report CS-73-403 (

ftp://reports.stanford.edu/pub/cstr/reports/cs/tr/73/403/CS-TR-73-403.pdf
). December, 1973 — Примеч. автора.