Давайте заглянем в этот самый вайб-код
Начал появляться код тех самых навайбкоденных проектов, который изменит мир и т. д. Ну а мы начинаем потихоньку смотреть код этих проектов, в том числе и сквозь призму статического анализа.
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, и какое будет выравнивание. Вот этот код:
Заключение
На этом пока всё. Если у вас есть на примете открытый код vibe-проекта, то оставьте в комментариях ссылку. Будем потихоньку смотреть, что там интересного.