Давайте заглянем в этот самый вайб-код⁠⁠

Оригинальная ссылка на материал здесь. Автор – Андрей Карпов.

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

Vib-OS – World's First Vibecoded AI Operating System

На глаза попалась новость "ИИ навайбкодил операционную систему. Как результат, DOOM не запускается, интернет не включается" о проекте Vib-OS. Решил глянуть, что там, полистав код и запустив статический анализатор PVS-Studio.

Проект на самом деле очень маленький. Операционная система — это только звучит громко. Посчитаем размер. Для начала я убрал оттуда заимствованные элементы, т. е. файлы, в которых нет "vibeos", "vibcode" и "vib-os". Затем ресурсы, представленные в виде массивов:

В итоге осталось около 110 файлов, содержащих 35 тыс. строк кода на C. Это очень мало, и я не думал, что там вообще будет что-то, о чём можно написать. Однако быстро выяснилось, что я вижу в нём как ошибки, так и кринжовые моменты, про которые хочется рассказать.

Многословие

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

Другой пример. В doom_libc.c реализованы функции:

При этом ниже в том же файле символы местами проверяются "в лоб" без использования этих функций:

I Like to Move It, Move It

Постоянно встречается однотипный код копирования байтов, который так и напрашивается на замену на memcpy, srtcpy и т. п. Одних только одинаковых функций копирования строк я встретил четыре штуки.

Постоянно в разных местах "вручную" копируются различные буферы:

Все эти четверостишья можно заменить на memcpy или, по крайней мере, на одну нормально написанную функцию копирования. Тем более что временами делается попытка скопировать буфер с претензией на оптимизацию:

Чувствуется, что ИИ не лень код писать и он очень любит копировать данные туда-сюда. Вот, например, функция bt_set_local_name просто перекладывает строку в буфер размером 248 байт и передаёт её дальше в hci_send_cmd.

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

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

Баги

А что там про ошибочки? Из-за длинных функций и "пухлости" кода просматривать некоторые предупреждения статического анализатора сложно. Впрочем, в некоторых случаях ошибки очевидны.

Бессмысленные проверки

Предупреждение PVS-Studio: V517 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical error presence. Check lines: 697, 1029. terminal.c 697

Два раза выполняется проверка, что строка начинается на ping. Но обработчики разные, так что тут явно что-то получилось не так, как задумывалось.

Другой похожий баг:

Предупреждение PVS-Studio: V517 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical error presence. Check lines: 1962, 2335. window.c 1962

Проверка для блоков кода /* Clock window */ и /* Clock */ идентична:

Соответственно, перед нами ошибка — недостижимый код.

Дублирование кода

Встречаются продублированные блоки кода:

Одно из предупреждений PVS-Studio: V519 The 'fctx.slot_w' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 1242, 1245. window.c 1245

Другой случай:

Предупреждение PVS-Studio: V760 Two identical blocks of text were found. The second block begins from line 2558. window.c 2543

Следующий фрагмент демонстрирует, что опечатку может допустить не только человек:

Предупреждение PVS-Studio: V560 A part of conditional expression is always false: btn_char == '+'. window.c 1713

Здесь что-то не так с условием. Возможно, оно должно быть другим. Нет смысла повторно проверять переменную на равенство символу +.

Выравнивание данных

Напоследок опасные игры с выравниванием данных:

Предупреждения PVS-Studio:

• V1032 The pointer 'dst' is cast to a more strictly aligned pointer type. window.c 3108

• V1032 The pointer 'src' is cast to a more strictly aligned pointer type. window.c 3109

Этот код может работать, но он очень опасен. Если входные указатели окажутся выровнены не по 64-битной границе, возникнет неопределённое поведение.

Произойдёт это или нет, затрудняюсь сказать. Если честно, я просто поленился разобрать, как будет работать код, вызывающий функцию fast_memcpy_line, и какое будет выравнивание. Вот этот код:

В любом случае код выглядит очень опасным и незащищённым от неправильно использования. Лучше так не делать. Подробнее тему выравнивания данных и связанных с этим ошибок моя коллега недавно разбирала в статье "Тихий враг или молчаливый союзник: коротко о выравнивании в C++": часть 1, часть 2.

Заключение

На этом пока всё. Если у вас есть на примете открытый код vibe-проекта, то оставьте в комментариях ссылку. Будем потихоньку смотреть, что там интересного.