exponenta event banner

CERT C: Rec. DCL19-C

Минимизируйте возможности переменных и функций

Описание

Определение правила

Минимизируйте возможности переменных и функций.[1]

Реализация Polyspace

Эта проверка проверяет на наличие следующих проблем:

  • Функция или объект объявлены без статического спецификатора и указаны только в одном файле.

  • Объект, заданный за пределами необходимых возможностей.

Примеры

расширить все

Проблема

Флажки проверки правил:

  • Объекты, которые определены в возможности без static спецификатор, который используется только в одном файле.

  • Функции, которые заданы без static спецификатор, но вызываемый только в одном файле.

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

Объекты, которые определены в возможности без static спецификатор, который используется только в одном файле.

Функции, которые заданы без static спецификатор, но вызываемый только в одном файле.

Polyspace® Bug Finder™ и Polyspace Code Prover™ по-разному проверить это правило кодирования. Анализы могут привести к различным результатам.

Чекер не помечает эту проблему в Polyspace по умолчанию во время анализа You Code. Смотрите Checkers Deactivated in Polyspace как You Code Default Analysis (Polyspace Bug Finder Access).

Риск

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

Пример - Переменная с внешним редактированием, используемая в одном файле

Заголовочный файл:

/* file.h */
extern int var;

Первый исходный файл:

/* file1.c */
#include "file.h"

int var;    /* Compliant */
int var2;   /* Non compliant */
static int var3; /* Compliant */

void reset(void);

void reset(void) {
    var = 0;
    var2 = 0;
    var3 = 0;
}

Второй исходный файл:

/* file2.c */
#include "file.h"

void increment(int var2);

void increment(int var2) {
    var++;
    var2++;
}

В этом примере:

  • Декларация var соответствует, потому что var объявляется с внешним редактированием и используется в нескольких файлах.

  • Декларация var2 не совместим, потому что var2 объявляется с внешним редактированием, но используется только в одном файле.

    Может показаться, что var2 определяется в обоих файлах. Однако во втором файле var2 является параметром без редактирования и не совпадает с параметром var2 в первом файле.

  • Декларация var3 соответствует, потому что var3 объявляется внутренним редактированием (с static спецификатор) и используется только в одном файле.

Пример - Функция с внешним редактированием, используемая в одном файле

Заголовочный файл:

/* file.h */
extern int var;
extern void increment1 (void);

Первый исходный файл:

/* file1.c */
#include "file.h"

int var;

void increment2(void);
static void increment3(void);
void func(void);

void increment2(void) { /* Non compliant */
    var+=2;
}

static void increment3(void) { /* Compliant */
    var+=3;
}

void func(void) {
    increment1();
    increment2();
    increment3();
}

Второй исходный файл:

/* file2.c */
#include "file.h"

void increment1(void) { /* Compliant */
    var++;
}

В этом примере:

  • Определение increment1 соответствует, потому что increment1 определяется внешним редактированием и вызывается в другом файле.

  • Декларация increment2 не совместим, потому что increment2 определяется внешним редактированием, но вызывается в том же файле и нигде больше.

  • Декларация increment3 соответствует, потому что increment3 определяется внутренним редактированием (с static спецификатор) и вызывается в том же файле и нигде больше.

Проблема

Проблема возникает, когда идентификатор объекта появляется только в одной функции, но объект определяется за пределами возможностей.

Флажки проверки правил static объекты, которые доступны только в одной функции, но объявлены в области файлов.

Риск

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

Пример - Объект, объявленный в Возможности, но используемый в одной функции
static int ctr;   /* Non compliant */

int checkStatus(void);
void incrementCount(void);

void incrementCount(void) {
    ctr=0;
    while(1) {
        if(checkStatus())
            ctr++;
    }
}

В этом примере объявление ctr не совместим, поскольку он объявлен в области файлов, но используется только в функции incrementCount. Объявить ctr в теле incrementCount будет MISRA C®-совместим.

Проверяйте информацию

Группа: Рек. 02. Объявления и инициализация (DCL)
Введенный в R2019a

[1] Это программное обеспечение было создано MathWorks, включающее фрагменты: «Сайт SEI CERT-C», © 2017 Университет Карнеги Меллон, Веб-сайт SEI CERT-C + + © 2017 Университет Карнеги Меллон, "Стандарт кодирования SEI CERT C - Правила разработки безопасных, Надежные и безопасные системы - 2016 Edition ", © 2016 Университет Карнеги Меллон, и "Стандарт кодирования SEI CERT C++ - Правила разработки безопасных, Надежные и безопасные системы в C++ - 2016 Edition "© 2016 Университет Карнеги Меллон, с специального разрешения от его Института программной инженерии.

ЛЮБОЙ МАТЕРИАЛ УНИВЕРСИТЕТА КАРНЕГИ МЕЛЛОН И/ИЛИ ЕГО ИНЖЕНЕРНОГО ИНСТИТУТА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, СОДЕРЖАЩИЙСЯ В НАСТОЯЩЕМ ДОКУМЕНТЕ, ПОСТАВЛЯЕТСЯ НА БАЗИСЕ «КАК ЕСТЬ». УНИВЕРСИТЕТ КАРНЕГИ МЕЛЛОН НЕ ДАЕТ НИКАКИХ ГАРАНТИЙ, ВЫРАЖЕННЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, В ОТНОШЕНИИ ЛЮБОГО ВОПРОСА, ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯСЬ, ГАРАНТИЮ ПРИГОДНОСТИ ДЛЯ ЦЕЛЕЙ ИЛИ КОММЕРЧЕСКОЙ ВЫГОДЫ, ИСКЛЮЧИТЕЛЬНОСТИ, ИЛИ УНИВЕРСИТЕТ КАРНЕГИ МЕЛЛОН НЕ ДАЕТ НИКАКИХ ГАРАНТИЙ В ОТНОШЕНИИ СВОБОДЫ ОТ ПАТЕНТА, ТОВАРНОГО ЗНАКА ИЛИ НАРУШЕНИЯ АВТОРСКИХ ПРАВ.

Это программное обеспечение и связанная с ним документация не были рассмотрены и не одобрены Университетом Карнеги-Меллон или его Институтом программной инженерии.