Объявление той же функции или объекта несовместимыми способами
Проблема происходит, когда внешние идентификаторы не отличны.
Внешние идентификаторы являются единицами, объявленными с глобальной областью видимости или классом памяти extern
.
Polyspace® рассматривает два имени как отличные, если существует различие между их первым 31 символом. Если различие между двумя именами происходит только вне первого 31 символа, они могут быть легко приняты друг за друга. Удобочитаемость кода уменьшается. Для C90 различие должно произойти между первыми 6 символами. Чтобы использовать проверку правил C90, используйте значение c90
для опции C standard version (-c-version)
.
int engine_temperature_raw; int engine_temperature_scaled; /* Non-compliant */ int engin2_temperature; /* Compliant */
В этом примере, идентификатор engine_temperature_scaled
имеет те же первые шесть символов как предыдущий идентификатор, engine_temperature_raw
.
int engine_exhaust_gas_temperature_raw; int engine_exhaust_gas_temperature_scaled; /* Non-compliant */ int eng_exhaust_gas_temp_raw; int eng_exhaust_gas_temp_scaled; /* Compliant */
В этом примере, идентификатор engine_exhaust_gas_temperature_scaled
имеет тот же первый 31 символ как предыдущий идентификатор, engine_exhaust_gas_temperature_raw
.
/* file1.c */ int abc = 0;
/* file2.c */ int ABC = 0; /* Non-compliant */
В этом примере, поддержка внедрения 6 значительных нечувствительных к регистру символов во внешних идентификаторах. Идентификаторы в двух переводах отличаются, но не отличны в их значительных символах.
Несоответствие объявления происходит, когда объявление функции или объявление переменной не совпадают с другими экземплярами функции или переменной.
Когда несоответствие происходит между двумя объявлениями переменной в различных единицах компиляции, типичный компоновщик следует алгоритму, чтобы выбрать одно объявление для переменной. Если вы ожидаете объявление переменной, которое отличается от один выбранный компоновщиком, вы видите неожиданные результаты, когда переменная используется.
Подобная проблема может произойти с несоответствием в объявлениях функции.
Фиксация зависит от типа несоответствия объявления. Если оба объявления действительно относятся к тому же объекту, используйте то же объявление. Если объявления относятся к различным объектам, изменяют названия той из переменных. Если вы меняете имя переменной, не забудьте вносить изменение во всех местах, которые используют переменную.
Иногда, несоответствия объявления могут произойти, потому что объявления затронуты предыдущими директивами предварительной обработки. Например, объявление происходит в макросе, и макрос задан на одном пути к включению, но неопределенный в другом. Эти несоответствия объявления могут быть хитрыми, чтобы отладить. Идентифицируйте расхождение между двумя путями к включению и зафиксируйте конфликтные макроопределения.
Если вы не хотите устранять проблему, добавьте комментарии в свой результат или код, чтобы избежать другого анализа. Смотрите Результаты Polyspace Адреса Через Исправления ошибок или Выравнивания.
file1.c
int foo(void) { return 1; }
file2.c
double foo(void);
int bar(void) {
return (int)foo();
}
В этом примере file1.c объявляет foo()
как возврат целого числа. В file2.c, foo()
объявляется как возврат двойного. Это различие повышает дефект на втором экземпляре foo
в file2.
Одна возможная коррекция должна изменить объявления функции так, чтобы они соответствовали. В этом примере, путем изменения объявления foo
в file2.c, чтобы совпадать с file1.c, фиксируется дефект.
file1.c
int foo(void) { return 1; }
file2.c
int foo(void); int bar(void) { return foo(); }
test1.c #include "square.h" #include "circle.h" struct aCircle circle; struct aSquare square; int main(){ square.side=1; circle.radius=1; return 0; } | test2.c #include "circle.h" #include "square.h" struct aCircle circle; struct aSquare square; int main(){ square.side=1; circle.radius=1; return 0; } |
circle.h #pragma pack(1) extern struct aCircle{ int radius; } circle; | square.h extern struct aSquare {
unsigned int side:1;
} square; |
В этом примере дефект несоответствия объявления повышен на square
в square.h, потому что Polyspace выводит тот square
в square.h не имеет того же выравнивания как square
в test2.c. Эта ошибка происходит потому что #pragma pack(1)
оператор в circle.h объявляет определенное выравнивание. В test2.c circle.h включен прежде square.h. Поэтому #pragma pack(1)
оператор от circle.h не сбрасывается к выравниванию по умолчанию после aCircle
структура. Из-за этого пропуска test2.c выводит что aSquare square
структура также имеет выравнивание 1
байт.
Одна возможная коррекция должна сбросить выравнивание структуры после aCircle
объявление struct. Для GNU® или компиляторов Microsoft® Visual, зафиксируйте дефект путем добавления #pragma pack()
оператор в конце circle.h.
test1.c #include "square.h" #include "circle.h" struct aCircle circle; struct aSquare square; int main(){ square.side=1; circle.radius=1; return 0; } | test2.c #include "circle.h" #include "square.h" struct aCircle circle; struct aSquare square; int main(){ square.side=1; circle.radius=1; return 0; } |
circle.h #pragma pack(1) extern struct aCircle{ int radius; } circle; #pragma pack() | square.h extern struct aSquare { unsigned int side:1; } square; |
Другие компиляторы требуют различного #pragma pack
синтаксис. Для вашего синтаксиса см. документацию для своего компилятора.
Ignore pragma pack directives
ОпцияОдна возможная коррекция должна добавить Ignore pragma pack directives
опция к вашему анализу Средства поиска Ошибки. Если вы хотите, чтобы выравнивание структуры изменилось для каждой структуры, и вы не хотите видеть этот дефект Declaration mismatch, использовать эту коррекцию.
На панели Настройки выберите панель Advanced Settings.
В поле Other введите -ignore-pragma-pack
.
Повторно выполните свой анализ.
Дефект Declaration mismatch разрешен.
Разрешимость: разрешимый |
[1] Выписки из стандарта "Техническая характеристика ISO/IEC TS 17961 - 2013-11-15" воспроизводятся с соглашением о AFNOR. Только исходный и полный текст стандарта, как опубликовано Выпусками AFNOR - доступный через веб-сайт www.boutique.afnor.org - имеет нормативное значение.
1. Если смысл перевода понятен, то лучше оставьте как есть и не придирайтесь к словам, синонимам и тому подобному. О вкусах не спорим.
2. Не дополняйте перевод комментариями “от себя”. В исправлении не должно появляться дополнительных смыслов и комментариев, отсутствующих в оригинале. Такие правки не получится интегрировать в алгоритме автоматического перевода.
3. Сохраняйте структуру оригинального текста - например, не разбивайте одно предложение на два.
4. Не имеет смысла однотипное исправление перевода какого-то термина во всех предложениях. Исправляйте только в одном месте. Когда Вашу правку одобрят, это исправление будет алгоритмически распространено и на другие части документации.
5. По иным вопросам, например если надо исправить заблокированное для перевода слово, обратитесь к редакторам через форму технической поддержки.