Вызывание функций с неправильными аргументами
Проблема происходит, когда все объявления объекта или функции не используют те же имена и вводят спецификаторы.
Средство проверки правила обнаруживает ситуации, где названия параметра или типы данных отличаются между многократными объявлениями или объявлением и определением. Средство проверки рассматривает объявления во всех модулях перевода и отмечает проблемы, которые вряд ли будут обнаружены компилятором.
Polyspace® Bug Finder™ и Polyspace Code Prover™ проверяют это правило кодирования по-другому. Исследования могут привести к различным результатам.
Последовательно использующие названия параметра и типы через объявления того же объекта или функции поощряют более сильный ввод. Легче проверять, что тот же функциональный интерфейс используется через все объявления.
extern int div (int num, int den); int div(int den, int num) { /* Non compliant */ return(num/den); }
В этом примере нарушено правило, потому что названия параметра в объявлении и определении переключаются.
typedef unsigned short width; typedef unsigned short height; typedef unsigned int area; extern area calculate(width w, height h); area calculate(width w, width h) { /* Non compliant * return w*h; }
В этом примере нарушено правило, потому что второй аргумент функции calculate
имеет тип данных:
height
в объявлении.
width
в определении.
Правило нарушено даже при том, что базовый тип height
и width
идентичен.
Ненадежный бросок указателя функции происходит, когда указатель функции брошен к другому указателю функции, который имеет различный аргумент, или возвратите тип.
Этот дефект применяется, только если кодовый язык для проекта является C.
Если вы бросаете указатель функции к другому указателю функции с различным аргументом или возвращаете тип и затем используете последний указатель функции, чтобы вызвать функцию, поведение не определено.
Избегайте броска между двумя указателями функции с несоответствием в аргументе или возвратите типы.
Смотрите примеры мер ниже.
Если вы не хотите устранять проблему, добавьте комментарии в свой результат или код, чтобы избежать другого анализа. Смотрите Результаты Polyspace Адреса Через Исправления ошибок или Комментарии.
#include <stdio.h>
#include <math.h>
#include <stdio.h>
#define PI 3.142
double Calculate_Sum(int (*fptr)(double))
{
double sum = 0.0;
double y;
for (int i = 0; i <= 100; i++)
{
y = (*fptr)(i*PI/100);
sum += y;
}
return sum / 100;
}
int main(void)
{
double (*fp)(double);
double sum;
fp = sin;
sum = Calculate_Sum(fp);
/* Defect: fp implicitly cast to int(*) (double) */
printf("sum(sin): %f\n", sum);
return 0;
}
Указатель функции fp
объявляется как double (*)(double)
. Однако мимоходом это, чтобы функционировать Calculate_Sum
, fp
неявно брошен к int (*)(double)
.
Одно возможное исправление должно проверять, что указатель функции в определении Calculate_Sum
имеет тот же аргумент, и возвратите тип как fp
. Этот шаг убеждается, что fp
неявно не брошен к различному аргументу, или возвратите тип.
#include <stdio.h> #include <math.h> #include <stdio.h> # define PI 3.142 /*Fix: fptr has same argument and return type everywhere*/ double Calculate_Sum(double (*fptr)(double)) { double sum = 0.0; double y; for (int i = 0; i <= 100; i++) { y = (*fptr)(i*PI/100); sum += y; } return sum / 100; } int main(void) { double (*fp)(double); double sum; fp = sin; sum = Calculate_Sum(fp); printf("sum(sin): %f\n", sum); return 0; }
Разрешимость: неразрешимый |
[1] Выписки из стандарта "Техническая характеристика ISO/IEC TS 17961 - 2013-11-15" воспроизводятся с соглашением о AFNOR. Только исходный и полный текст стандарта, как опубликовано Выпусками AFNOR - доступный через веб-сайт www.boutique.afnor.org - имеет нормативное значение.
1. Если смысл перевода понятен, то лучше оставьте как есть и не придирайтесь к словам, синонимам и тому подобному. О вкусах не спорим.
2. Не дополняйте перевод комментариями “от себя”. В исправлении не должно появляться дополнительных смыслов и комментариев, отсутствующих в оригинале. Такие правки не получится интегрировать в алгоритме автоматического перевода.
3. Сохраняйте структуру оригинального текста - например, не разбивайте одно предложение на два.
4. Не имеет смысла однотипное исправление перевода какого-то термина во всех предложениях. Исправляйте только в одном месте. Когда Вашу правку одобрят, это исправление будет алгоритмически распространено и на другие части документации.
5. По иным вопросам, например если надо исправить заблокированное для перевода слово, обратитесь к редакторам через форму технической поддержки.