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

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:V517The 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:V517The 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:V519The 'fctx.slot_w' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 1242, 1245. window.c 1245

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

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

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

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

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

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

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

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

• V1032The pointer 'dst' is cast to a more strictly aligned pointer type. window.c 3108
• V1032The pointer 'src' is cast to a more strictly aligned pointer type. window.c 3109

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

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

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

Заключение

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

Скучный вывод. Пишите вы код руками или создаёте его с помощью ИИ, чтобы он был качественным и надёжным, вы должны делать обзоры кода, использоватьанализатор PVS-Studioи другие практикиРБПО.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov.Let's dig into some vibe code.

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

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:V517The 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:V517The 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:V519The 'fctx.slot_w' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 1242, 1245. window.c 1245

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

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

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

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

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

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

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

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

• V1032The pointer 'dst' is cast to a more strictly aligned pointer type. window.c 3108
• V1032The pointer 'src' is cast to a more strictly aligned pointer type. window.c 3109

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

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

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

Заключение

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

Скучный вывод. Пишите вы код руками или создаёте его с помощью ИИ, чтобы он был качественным и надёжным, вы должны делать обзоры кода, использоватьанализатор PVS-Studioи другие практикиРБПО.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov.Let's dig into some vibe code.