Можно попробовать пропатчить внутренний глибц, а именно функцию time().

Это не мой путь.

А там разве не ожидаемый результат?

Я бы ожидал получить -1, но судя по приведенному результату, получено UINT_MAX, что не есть правильно.

Яж постил исправленный код:

#include <stdio.h>
#include <inttypes.h>

void a(void) {
  uint32_t a=10,b=11;
  int64_t c;
  c=(a-b);
  printf("C: %li\n",(long int)c);
}
void b(void) {
  uint8_t a=10,b=11;
  int16_t c;
  c=(a-b);
  printf("C: %i\n",c);
}

int main(void) { a(); b(); return 0; }

Яж постил исправленный код

Посмотри на формат в printf. Я его специально испортил, чтобы GCC написал тип параметра в предупреждениях.

Я бы ожидал получить -1

с какого перепуга? результат двух uint32 есть uint32. проблема в том, что в printf неверные спецификаторы, захардкоженные под встроенные типы.

Я бы ожидал получить -1,

Вычитаются беззнаковые числа, для которых явно описано поведение при переполнении — они «проворачиваются». Потом 32-битное беззнаковое расширяется до знакового 64-битного, которое может вместить это число.

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

Посмотри на формат в printf. Я его специально испортил, чтобы GCC написал тип параметра в предупреждениях.

У нас какбы типизированный язык, и так известно какие типы передаём в printf и какие ожидаем получить, если пишем %li или PRId64, как правильно заметил vvviperrr .

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

Тут и clang ругнется:

$ gcc tmp/t.cpp
tmp/t.cpp:10:24: warning: format specifies type 'long' but the argument has type 'int64_t' (aka 'long long') [-Wformat]
    printf("C: %li\n", c);
               ~~~     ^
               %lli
1 warning generated.

Или вы про разницу a и b, где b > a?

Тут уже написали, что Coverity предоставляет опенсорс-проектам бесплатный сервис проверки? Наверное, написали. Ну ничего, я тоже напишу: Coverity предоставляет опенсорс-проектам бесплатный сервис проверки.

Я про PVS-Studio для Linux (комментарий) при сборки под x64.

чтобы ошибки программиста отлавливать

V0041: Ваша программа что-то делает. Это источник ошибок. Советуем изменить программу так, чтобы она ничего не делала.

А если серьёзно, то что тут отлавливать? Расширение типов? Расширение со сменой знака?

Вас не смущает что один и тот же код выполняется по разному, если собрать под x86 и x64? Или то, что результат иной при увеличении типов в 4 раза?

и так известно какие типы

Судя по тому, что ты вопрос задал, не известно. Твой пример о том, что вычитая два uint32_t, получаем unsigned int, а вычитая два uint8_t, получаем int. А совсем не про printf. Мой пример это наглядно показывает, тогда как в твоём это скрыто.

Как минимум, отлавливать, что операция двух известных на этапе беззнаковых компиляции чисел дает отрицательный результат.

Ну ничего, я тоже напишу: Coverity предоставляет опенсорс-проектам бесплатный сервис проверки

Ну не все же в опенсорс пишут.

Вас не смущает что один и тот же код выполняется по разному, если собрать под x86 и x64?

Это потому что ты не используешь PRId64 и PRId16 в формате printf. Если их использовать, будет одинаковый результат и там и тут. Ты же в курсе, что ты в «стек» пихаешь 64-битное число, а забираешь 32-битное?

Или то, что результат иной при увеличении типов в 4 раза?

Меня это не смущает, это правила языка Си. Я учил его не по книжке, а по кусочкам то там, то тут. Поэтому у меня нет ощущения «да знаю я всё», которое бывает у студентов после чтения методички. Это ощущение опасное, оно приводит вот к таким недоразумениям.

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

Просто, его вопрос намекал на то, что Coverity не «помог выявить несколько тысяч ошибок в опенсорс-ПО», а это неправда.

Пожалуй с Вами соглашусь:

sh-4.2$ cat main.c 
#include <stdio.h>
#include <inttypes.h>

void a(void) {
  uint32_t a=10,b=11;
  int64_t c;
  c=(a-b);
  printf("C: %"PRIi64"\n",c);
}
void b(void) {
  uint8_t a=10,b=11;
  int16_t c;
  c=(a-b);
  printf("C: %"PRIi16"\n",c);
}

int main(void) { a(); b(); return 0; }

sh-4.2$ gcc-6.2.0 -m32 -Wall -Wextra -Wpedantic main.c && ./a.out
C: 4294967295
C: -1

Но потенциальной проблемы это не отменяет.

На заметку: использование PRIi64 конечно правильно, но код получается уж крайне ублюдочный. ИМХО.

Или то, что результат иной при увеличении типов в 4 раза

если для тебя такое поведение новость - почитай про type promotion

если для тебя такое поведение новость - почитай про type promotion

Вы так говорите, будто анализаторы ненужны.

отнюдь. но пользование анализатором не гарантирует 100% защиты от ошибок. отсюда мне и неясен твой пример.

Мой пример показывает, что никакие опции компилятора, никакие анализаторы не могут указать на потенциальную проблему

а кто утверждал обратное?

Его нельзя купить, а можно только арендовать.

А с Coverity (не для опенсoрса) как? Они разве продают «бессрочные версии»? Да и цена, насколько я знаю, «немного» побольше.

Разработчики анализатора представили свой продукт. Я кинул им пример кода, который содержит потенциальную ошибку, убедился что их анализатор эту ошибку не поймает. А вы в свою очередь набросились на меня за мою криворукость, из-за двух ошибок, которые я допустил в примере. Обе ошибки я признал и код поправил.

Вы до сих пор продолжаете со мной разговаривать, Вы хотите донести до меня что-то ещё?

Ничего интересного в нем нет. Работы там на 5 минут. Смотри в удаленных.

Путь — впустую работать для кого-то не получив из этого ровным счётом ничего? Ок.

убедился что их анализатор эту ошибку не поймает

Анализатор на строке «printf(„C: %li\n“, c);» выдаёт: V576 Incorrect format. Consider checking the second actual argument of the 'printf' function. The actual argument equals '4294967295'.

А где чувак по имени mandala. Ну тот, который за «13 сребренников» защищал ПиВаС-Студио.

Ответ протух, надо тестировать на этом:

#include <stdio.h>
#include <inttypes.h>

void a(void) {
  uint32_t a=10,b=11;
  int64_t c;
  c=(a-b);
  printf("C: %"PRIi64"\n",c);
}
void b(void) {
  uint8_t a=10,b=11;
  int16_t c;
  c=(a-b);
  printf("C: %"PRIi16"\n",c);
}

int main(void) { a(); b(); return 0; }

Ошибку вида:

 if (a=3)

Ошибку вида:

 int32_t a;
 b=a<<33;

Чем моя хуже?

Шикарная новость!

в упор не понимаю, где ты тут увидел ошибку? тебе не нравится, что результаты разные? тебе уже 2 человека ответили, есть такая вещь - type promotion. в чем ошибка то? в стандарте?

Не его смена наверно

Шикарная новость!

А ваша компания сколько экземпляров закупила, если не секрет? С какими аналогами сравнивали?

В том, что человек имея знаковый тип присваивая туда разницу двух переменных ожидает получить отрицательный результат если разница между этими переменными отрицательная.

В том числе он это может успешно получить на типах другой размерности.

Путь — впустую работать для кого-то не получив из этого ровным счётом ничего? Ок.

Вы про бета-тестинг? Да, обидно. Но страдать из-за этого не стоит.

А зачем страдать? Разве это не весело?

в языке си операции не всегда проходят очевидным для «человека» способом. таких примеров куча. в данном примере нет ошибки, т.к стандарт четко регламентирует работу над типами меньше int.

А зачем страдать?

А я и не предлагал страдать.

Разве это не весело?

Понятия не имею.

Если честно, я не уловил суть примера.

А жаль. Подобный код у миллионов людей приводит к ошибкам:

<режим зануды>Понятно, что для того, кто задаёт вопрос - всё понятно. А вот тот кто слышит - может слышать другое или у него может быть несколько вариантов интерпретации. Задать вопрос - это тоже искусство.</режим зануды>

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

Ты предполагал страдание. А я вот удивляюсь, откуда и, главное, зачем?

Стандарт все регламентирует. Анализаторы не нужны?

Чем моя хуже?

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

В if(a=3) тоже нет ошибки. Там где есть ошибка компилятор выдаст предупреждение.

Мы тут анализатор обсуждаем, который должен искать ошибки в коде, код который пишут люди (часто с недостаточным багажём знаний)? Или тема уже сменилась, а я не заметил?

Я ни в коем разе не делаю выводов о качестве Вашего продукта. И не хочу Вас как-то унизить. Считайте, что это моя конструктивная критика. Делать выводы о Вашей конторе я буду по факту того, выявляется ли подобная ошибока в следующих версиях.

а какого вида предупреждения ты хочешь для своего примера? в каждой операции с типами меньше int кидать варнинг - внимание, продвижение типов?

на мой взгляд - для статического анализатора тут нечего анализировать.

Крутяк, анонимус торт!

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

c=(int64_t)a-b;

или

c=(uint32_t)a-b;

Чтобы подчеркнуть то, что Вы хотите сделать.

ключ

Кто-нибудь ключ выложит?

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