Если ваша программа большая, отладочная опция может принимать аргумент, указывающий, какую подсистему следует отлаживать. На основе этого аргумента можно установить различные флаговые переменные или, возможно, различные флаговые биты в одной отладочной переменной. Вот схема этой методики:
struct option options[] = {
...
{ "debug", required_argument, NULL, 'D' },
...
};
int main(int argc, char **argv) {
int c;
while ((c = getopt_long(argc, argv, "...D:")) != -1) {
switch (c) {
...
case 'D':
parse_debug(optarg);
break;
...
}
}
...
}
Функция parse_debug() считывает строку аргументов. Например, это может быть строка разделенных запятыми или пробелами подсистем, вроде "file,memory,ipc". Для каждого действительного имени подсистемы функция устанавливает бит в отладочной переменной:
extern int debugging;
void parse_debug(const char *subsystems) {
char *sp;
for (sp = subsystems; *sp != '\0';) {
if (strncmp(sp, "file", 4) == 0) {
debugging |= DEBUG_FILE;
sp += 4;
} else if (strncmp(sp, "memory", 6) == 0) {
debugging |= DEBUG_MEM;
sp += 6;
} else if (strncmp(sp, "ipc", 3) == 0) {
debugging |= DEBUG_IPC;
sp += 3;
...
}
while (*sp == ' ' || *sp == ',') sp++;
}
}
В конечном счете код приложения может затем проверить флаги:
if ((debugging & DEBUG_FILE) != 0) ...
/* В части программы для ввода/вывода */
if ((debugging & DEBUG_MEM) != 0) ... /* В менеджере памяти */
Использовать ли одну переменную с флаговыми битами, различные переменные или даже отладочный массив, индексируемый именованными константами (желательно из enum), зависит от вас.
Ценой оставления отладочного кода в исполняемом файле изделия является увеличение размера программы. В зависимости от размещения отладочного кода он может быть также более медленным, поскольку каждый раз осуществляются проверки, которые все время оказываются ложными, пока не будет включен режим отладки. И, как упоминалось, кто-нибудь может изучить вашу программу, что может быть неприемлемым для вас. Или еще хуже, недоброжелательный пользователь может включить столько отладочных возможностей, что программа замедлится до невозможности работать с ней! (Это называется атакой отказа в обслуживании (denial of service attack).)
Преимуществом, которое может быть большим, является то, что вашу уже установленную программу можно запустить с включенным режимом отладки без необходимости сначала построить, а затем загрузить специальную версию на сайт заказчика. Когда программное обеспечение установлено в удаленных местах, в которых может не быть людей и все, что вы можете сделать, это получить удаленный доступ к системе через Интернет (или, еще хуже, через медленное модемное соединение!), такая возможность может оказаться спасительным средством.
Наконец, можно использовать смешанную методику: условно компилируемый отладочный код для детальной, точной отладки, а постоянно присутствующий код для более грубого вывода.
15.4.2.2. Используйте специальные переменные окружения
Другой полезной уловкой является проверка вашим приложением специальных переменных окружения (документированных или иных). Это может быть особенно полезным для тестирования. Вот другой пример из нашего опыта с gawk, но сначала немного основ.
gawk использует функцию с названием optimal_bufsize() для получения оптимального размера буфера для ввода/вывода. Для небольших файлов функция возвращает размер файла. В противном случае, если файловая система определяет размер для использования при вводе/выводе, возвращается это значение (член st_blksize структуры struct stat, см. раздел 5.4.2 «Получение информации о файле»). Если этот член недоступен, optimal_bufsize() возвращает константу BUFSIZ из <stdio.h>. Оригинальная функция (в posix/gawkmisc.c) выглядела следующим образом:
1 /* optimal_bufsize --- определяет оптимальный размер буфера */
2
3 int
4 optimal_bufsize(fd, stb) /* int optimal_bufsize(int fd, struct stat *stb); */
5 int fd;
6 struct stat *stb;
7 {
8 /* инициализировать все члены нулями на случай, если ОС не использует их все. */
9 memset(stb, '\0', sizeof(struct stat));
10
11 /*
12 * System V.n, n < 4, не имеет в структуре stat размера
13 * системного блока файла. Поэтому нам нужно сделать разумную
14 * догадку. Мы используем BUFSIZ, поскольку именно это имелось
15 * в виду на первом месте.
16 */
17 #ifdef HAVE_ST_BLKSIZE
18 #define DEFBLKSIZE (stb->st_blksize ? stb->st_blksize : BUFSIZ)
19 #else
20 #define DEFBLKSIZE BUFSIZ
21 #endif
22
23 if (isatty(fd))
24 return BUFSIZ;
25 if (fstat(fd, stb) == -1)
26 fatal("can't stat fd %d (%s)", fd, strerror(errno));
27 if (lseek(fd, (off_t)0, 0) == -1) /* не обычный файл */
28 return DEFBLKSIZE;
29 if (stb->st_size > 0 && stb->st_size < DEFBLKSIZE) /* маленький файл */
30 return stb->st_size;
31 return DEFBLKSIZE;
32 }
Константа DEFBLKSIZE является «размером блока по умолчанию»; то есть значением из struct stat или BUFSIZ. Для терминалов (строка 23) или файлов, которые не являются обычными файлами (lseek() завершается неудачей, строка 27) возвращаемое значение также равно BUFSIZ. Для небольших обычных файлов используется размер файла. Во всех других случаях возвращается DEFBLKSIZE. Знание «оптимального» размера буфера особенно полезно в файловых системах, в которых размер блока больше BUFSIZ.
У нас была проблема, когда один из наших контрольных примеров отлично работал на нашей рабочей системе GNU/Linux и на любой другой системе Unix, к которой у нас был доступ. Однако, этот тест последовательно терпел неудачу на других определенных системах.