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

Пример с ошибкой

В следующем примере внутри функции повторно использовано имя глобальной переменной. Это одновременно приводит к невозможности доступа к локальной переменной и переполнению буфера в локальной переменной, т.к. для указания размера этого буфера используется глобальная переменная msgsize, которая указывает больший размер.

static char msg[100];
static const size_t msgsize = sizeof( msg);
 
void report_error(const char *str) {
  char msg[80];
  snprintf(msg, msgsize, "Error: %s\n", str);
  /* ... */
}
 
int main() {
  /* ... */
  report_error("some error");
}

Правильное решение

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

static char message[100];
static const size_t message_size = sizeof( message);
 
void report_error(const char *str) {
  char msg[80];
  snprintf(msg, sizeof( msg), "Error: %s\n", str);
  /* ... */
}
 
int main() {
  /* ... */
  report_error("some error");
}

Исключение

Аргументы функции при ее объявлении (но не определении) могут вступать в конфликт с именами глобальных переменных:

extern int name;
void f(char *name);   // объявление: тут нет проблем
// ...
void f(char *arg) {   // определение: имя должно отличаться!
  // use arg
}

Оценка риска

Строгость – низкая = 1
Вероятность – маловероятно = 1
Цена соблюдения – средняя = 2

Итого:
Приоритет: P2
Уровень: L3

Автоматическое обнаружение

Обнаруживать нарушение этой рекомендации умеют следующие тулзы:

LDRA tool suite V. 7.6.0
Splint V. 3.1.1
Compass/ROSE
Klocwork V. 9.1 (IF_MULTI_DECL, IF_MULTI_DEF, IF_MULTI_KIND)

02. Declarations and Initialization / DCL01-C

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

Однако, константные значения в Си можно задавать еще двумя способами: макроподстановками и перечислениями enum. Оба они имеют свои недостатки. Так макросы видны только в пределах компилируемого модуля, при отладке выглядят как константы, разбросанные по исходнику, а так же нет возможности явно указать их тип.

В случае перечислений – тип только int, зато не выделяется память. Отладчики представляют их как переменные, что тоже удобно.

Собственно и все. Не буду оскорблять достоинство читателя примерами определения константных переменных Хотя, если они вам необходимы, можете заглянуть на страницу стандарта, там они есть. Ссылка ниже.

Оценка риска

Строгость – низкая = 1
Вероятность – маловероятно = 1
Цена соблюдения – высокая = 1

Итого:
Приоритет: P1
Уровень: L3

Автоматическое обнаружение

Compass/ROSE умеет это

02. Declarations and Initialization / DCL00-C

Приветствую всех, кто заглядывает в мой блог!

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

Теперь найти бы время, для творческой переработки всего этого материала, что бы сделать его более удобочитаемым…

В следующих статьях речь пойдет об ошибках объявлений и инициализации.

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

Тут особо стоит отметить, что многие функции стандартной библиотеки (и прочих библиотеки сторонних разработчиков) на самом деле являются макросами. Например, memcpy(), printf(), и assert() могут быть макросами. По этому данное правило следует распространить и на использование препроцессорных директив в списках параметров функций.

Пример с ошибкой

В следующем примере автор использовал директивы препроцессора для определения платформенно-зависимого параметра в вызове memcpy(). Однако, если memcpy() является макросом, то этот участок кода приведет к неопределенному поведению.

memcpy(dest, src,
#ifdef PLATFORM1
  12
#else
  24
#endif
);

Правильное решение

#ifdef PLATFORM1
  memcpy(dest, src, 12);
#else
  memcpy(dest, src, 24);
#endif

Оценка риска

Строгость – низкая = 1
Вероятность – маловероятно = 1
Цена соблюдения – средняя = 2

Итого:
Приоритет: P2
Уровень: L3

01. Preprocessor / PRE32-C

С99 поддерживает универсальные имена символов, которые могут использоваться в идентификаторах, символьных константах и строковых литералах для обозначения символов не входящих в базовый набор. Универсальное имя символа начинается с \U или \u и последующих восьми, или четырех шестнадцатеричных цифр соответственно. Более подробно о стандарте UTF можно почитать в википедии, или в стандарте ISO/IEC 10646.

В стандарте C99, секция 5.1.1.2, параграф 4, говорится:

Если последовательность символов, синтаксически соответствующая универсальному имени символа образуется в результате конкатенации (6.10.3.3), поведение не определено.

Вообще, следует избегать применения универсальных имен символов в идентификаторах без крайней на то необходимости. Базового набора символов должно хватать практически для любого идентификатора.

Пример с ошибкой

#define assign(uc1, uc2, val) uc1##uc2 = val;
 
int \u0401;
assign( \u04, 01, 4);

Правильное решение

#define assign(ucn, val) ucn = val;
 
int \u0401;
assign( \u0401, 4);

Оценка риска

Строгость – низкая = 1
Вероятность – маловероятно = 1
Цена соблюдения – средняя = 2

Итого:
Приоритет: P2
Уровень: L3

01. Preprocessor / PRE30-C

Вообще-то странно конечно, что данная статья стандарта перекрывается с вот этой – “CERT. static и inline функции вместо макросов” чуть менее, чем полностью. Конечно, раз она есть совсем ее пропускать не хорошо, но сократить, думаю, не грех.

Раньше в этой серии статей уже говорилось, что в отличие от функций, макросы могут рассчитывать переданное в качестве параметра выражение по нескольку раз. И говорилось о приемуществе inline функций, перед функциональными макросами, сдесь же дается еще одно решение данной проблемы.

Пример с ошибкой (множественное вычисление аргумента)

1
2
3
4
5
6
7

#define ABS(x) (((x) < 0) ? -(x) : (x))
 
void f(int n) {
  int m;
  m = ABS(++n); // получится явно не то, что задумывалось
  /* ... */
}

После подстановки макроса исходный текст будет содержать:

5

m = (((++n) < 0) ? -(++n) : (++n));

Правильное решение

Решение с использованием inline функций описано в этой статье. Некоторые компиляторы поддерживают расширения, которые позволяют определять безопасные функциональные макросы. Например, в GCC безопасный макрос можно определить так:

#define ABS(x) ({int tmp = (x); tmp < 0 ? -tmp : tmp; })

Правда, при использовании таких расширений теряется портируемость кода и скомпилировать его компилятором не поддерживающим это расширение невозможно.

Оценка риска

Строгость – низкая = 1
Вероятность – вероятно = 2
Цена соблюдения – низкая = 3

Итого:
Приоритет: P6
Уровень: L2

01. Preprocessor / PRE12-C