Зачем делать игры, которые увидят немногие? | Разбаговка #6

У нас в гостях Слава Грис, разработчик игр, блогер. В выпуске:
- Точка входа: История о том, как Слава оказался в геймдеве (спойлер: опыт не всегда стоит на первом месте).
- Дух андеграунда: Что движет автором, когда он создает игры не «для всех».
- Бизнес на коленке: Как инди-разработчику не затеряться в океане ежедневных релизов и найти своего игрока.
- Свобода vs Мейнстрим: Почему быть «маленьким» разработчиком — это суперсила, и зачем делать игры, которые поймут немногие.

Вышел новый релиз PVS-Studio — 7.41. В нём улучшения для Unreal Engine, поддержка MISRA C 2023, обновление плагина для IntelliJ IDEA и другие полезные изменения.

На мой взгляд особого внимания заслуживает новый механизм "Удаление неактуальных маркеров подавления".

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

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

Для очистки кодовой базы от неактуальных маркеров в пакете поставки анализатора PVS-Studio предусмотрена специальная утилита — pvs-fp-cleaner.

Мы добавили в документацию раздел об использовании
PVS-Studio в SourceCraft

SourceCraft — платформа, с помощью которой можно разрабатывать исходный код, управлять версиями, тестировать, собирать, развёртывать и сопровождать программные продукты. Сервис представляет собой систему управления репозиториями кода для Git с отслеживанием ошибок и пайплайном CI/CD.

Читатели Хабра думаю сразу вспомнят "Объяснить с SourceCraft" в блоках кода.

В документации объясняется как запустить анализатор PVS-Studio и как работать с SARIF-отчётами.

Соответствующий раздел: Использование PVS-Studio в SourceCraft

Один из способов подавления ложных срабатываний PVS-Studio, это специальные комментарии в коде. К сожалению, постепенно в коде могут накапливаться неактуальные комментарии подавления. Такое происходит, если код изменился и не вызывает более подозрения у анализатора. Или анализатор стал лучше понимать задумки программистов и более не выдаёт в каких-то местах срабатываний.

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

Для C++ программистов и не только. Обзор 10 уроков, посвящённый написанию своего языка программирования. Полностью материалы бесплатно представлены здесь.

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

      char seq[32];
      int s = 0;
      seq[s++] = ':';
      seq[s++] = ' ';
      seq[s++] = 'i';
      seq[s++] = 'c';
      seq[s++] = 'm';
      seq[s++] = 'p';
      seq[s++] = '_';
      seq[s++] = 's';
      seq[s++] = 'e';
      seq[s++] = 'q';
      seq[s++] = '=';
      seq[s++] = '0' + i;
      seq[s++] = ' ';
      seq[s++] = 't';
      seq[s++] = 't';
      seq[s++] = 'l';
      seq[s++] = '=';
      seq[s++] = '6';
      seq[s++] = '4';
      seq[s++] = ' ';
      seq[s++] = 't';
      seq[s++] = 'i';
      seq[s++] = 'm';
      seq[s++] = 'e';
      seq[s++] = '=';
      /* Random-ish time 10-50ms */
      int time_ms = 15 + (i * 7) % 30;
      seq[s++] = '0' + (time_ms / 10);
      seq[s++] = '0' + (time_ms % 10);
      seq[s++] = ' ';
      seq[s++] = 'm';
      seq[s++] = 's';
      seq[s++] = '\n';
      seq[s] = '\0';

Может зато опечаток нет? Есть.

PVS-Studio: V560 A part of conditional expression is always false: btn_char == '+'. window.c 1713

Создал канал-дублёр в MAX: Бестиарий программирования

Ещё на тему разбухшего vibe-кода. Смотрю проект Vib-OS. Потом про него статья будет. Это очень маленький проект, если убрать сторонние сущности и различные ресурсы, хранящиеся в виде массивов в коде. По делу там около 35 тысяч строк кода в 110 файлах.

Так вот, на эти 110 файлов я насчитал как минимум 4 одинаковые функции копирования строк.

static void str_copy(char *dst, const char *src, int max) {
  int i = 0;
  while (src[i] && i < max - 1) {
    dst[i] = src[i];
    i++;
  }
  dst[i] = '\0';
}

static void str_cpy(char *dst, const char *src, int max) {
  int i = 0;
  while (src[i] && i < max - 1) {
    dst[i] = src[i];
    i++;
  }
  dst[i] = '\0';
}

static void strcpy_safe(char *dst, const char *src, size_t max) {
  size_t i = 0;
  while (src[i] && i < max - 1) {
    dst[i] = src[i];
    i++;
  }
  dst[i] = '\0';
}

static inline char *strncpy_safe(char *dst, const char *src, size_t n) {
    size_t i;
    for (i = 0; i < n - 1 && src[i]; i++) {
        dst[i] = src[i];
    }
    dst[i] = '\0';
    return dst;
}

Видимо у ИИ который это делал, любимый напев – I Like to Move It, Move It :) Частое (местами совершенно бестолковое) копирование массивов. Причём реализованное циклами, а не через memcpy.

В комментариях к предыдущему посту написали, что memcpy не проверяет завершающий ноль, поэтому плохо подходит для копирования строк. Это так, но я имел в виду, что в рассматриваемом проекте вообще очень много копирования данных "вручную", не являющихся строками. Постоянно встречается код вида:

uint8_t *src = buf + offset_in_block;
uint8_t *dst = (uint8_t *)inode;
for (size_t i = 0; i < sizeof(struct ext4_inode); i++) {
  dst[i] = src[i];
}

uint8_t *src = sb_buf;
uint8_t *dst = (uint8_t *)&fs->sb;
for (size_t i = 0; i < sizeof(struct ext4_superblock); i++) {
  dst[i] = src[i];
}

uint8_t *src = (uint8_t *)ptr;
uint8_t *dst = (uint8_t *)new_ptr;
for (size_t i = 0; i < old_size; i++) {
  dst[i] = src[i];
}

Все эти четверостишия могут быть заменены на один вызов memcpy.

Ещё пример. Функция bt_set_local_name просто перекладывает строку в буфер размером 248 байт и передаёт её в hci_send_cmd.

int bt_set_local_name(const char *name)
{
    uint8_t params[248] = {0};
    int len = 0;
    
    while (name[len] && len < 247) {
        params[len] = name[len];
        len++;
    }
    
    return hci_send_cmd(HCI_OP_WRITE_LOCAL_NAME, params, 248);
}

Посмотрим, что происходит со строкой дальше:

static int hci_send_cmd(uint16_t opcode, void *params, uint8_t plen)
{
    uint8_t buf[256];
    
    buf[0] = HCI_COMMAND_PKT;
    
    struct hci_command_hdr *hdr = (struct hci_command_hdr *)&buf[1];
    hdr->opcode = opcode;
    hdr->plen = plen;
    
    if (plen > 0 && params) {
        for (int i = 0; i < plen; i++) {
            buf[4 + i] = ((uint8_t *)params)[i];
        }
    }
    
    /* TODO: Send via USB bulk endpoint */
    printk(KERN_DEBUG "BT: Send cmd opcode=0x%04x len=%d\n", opcode, plen);
    
    return 0;
}

Формируется новый буфер из специального заголовка и переданной строки. Дальше этот буфер пока не используется, но суть не в этом. Непонятно, зачем вообще был нужен промежуточный буфер в bt_set_local_name. Код можно сократить, попутно ускорив его, убрав одно копирование.