Сообщение Re[5]: И еще рассуждения об ИИ от 01.02.2026 14:11
Изменено 01.02.2026 14:16 Sinclair
Re[5]: И еще рассуждения об ИИ
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что значит неизвестной заранее структуры ? Ему скармливали код, а он искал в нем дефекты.
Это значит, что никакой специфичной для инструмента разметки нет. Просто даём код, и он ищет в нём любые дефект.
PD>Работал он ЕМНИМ на per- source file основе, поэтому ошибки, размытые между разными файлами, не находил.
А ИИ прекрасно анализирует ошибки, размытые между файлами.
PD>Ну насколько я это понимаю, это можно сформулировать чуть короче. В этот Map добавляются элементы, а this block его не очищает, так что может дело закончиться heap overflow.
Речь о неполной очистке. Когда мы какой-то из объектов разрушили, а соответствующий ему объект из мапы удалить забыли.
PD>Для Java или C# это отловить действительно не так просто. Более того, это может быть неверно. Кто его, этот map знает, может на него еще какая-то ссылка есть извне (не лучшая практика, но и не запрещено), и когда job reaches a terminal status, этим map кто-то и займется совсем в другом месте, и там использует и очистит — через пару интерфейсов и несколько паттернов
Но ИИ нашёл, что нигде в проекте этой очистки нет. И что по логике, которая там присутствует явно в виде документов проекта на естественном языке и неявно — в виде структуры кода, очистку нужно делать именно тут.
PD>Но PVS работал для C++, когда я с ним имел дело, а там все намного проще — есть у этого класса деструктор ("this block"), а в нем не вызывается delete или free для вложенного map. Классический memory leak. Такое он ловить умел.
This block — это не класс. Это просто текст на английском языке: "в этом блоке выполняется очистка задания, достигшего терминального статуса".
PD>https://pvs-studio.com/en/blog/posts/cpp/0543/
Это всё не то. PVS умеет ваш п.5? А это как раз оно — "принять или отвергнуть". Там если он не нашёл, к чему прикопаться, то просто ставит "лайк".
При том, что отрабатывает эта штука уже после того, как все линтеры, форматтеры, статические верификаторы и юнит-тесты отработали.
PD>Что значит неизвестной заранее структуры ? Ему скармливали код, а он искал в нем дефекты.
Это значит, что никакой специфичной для инструмента разметки нет. Просто даём код, и он ищет в нём любые дефект.
PD>Работал он ЕМНИМ на per- source file основе, поэтому ошибки, размытые между разными файлами, не находил.
А ИИ прекрасно анализирует ошибки, размытые между файлами.
PD>Ну насколько я это понимаю, это можно сформулировать чуть короче. В этот Map добавляются элементы, а this block его не очищает, так что может дело закончиться heap overflow.
Речь о неполной очистке. Когда мы какой-то из объектов разрушили, а соответствующий ему объект из мапы удалить забыли.
PD>Для Java или C# это отловить действительно не так просто. Более того, это может быть неверно. Кто его, этот map знает, может на него еще какая-то ссылка есть извне (не лучшая практика, но и не запрещено), и когда job reaches a terminal status, этим map кто-то и займется совсем в другом месте, и там использует и очистит — через пару интерфейсов и несколько паттернов
Но ИИ нашёл, что нигде в проекте этой очистки нет. И что по логике, которая там присутствует явно в виде документов проекта на естественном языке и неявно — в виде структуры кода, очистку нужно делать именно тут.
PD>Но PVS работал для C++, когда я с ним имел дело, а там все намного проще — есть у этого класса деструктор ("this block"), а в нем не вызывается delete или free для вложенного map. Классический memory leak. Такое он ловить умел.
This block — это не класс. Это просто текст на английском языке: "в этом блоке выполняется очистка задания, достигшего терминального статуса".
PD>https://pvs-studio.com/en/blog/posts/cpp/0543/
Это всё не то. PVS умеет ваш п.5? А это как раз оно — "принять или отвергнуть". Там если он не нашёл, к чему прикопаться, то просто ставит "лайк".
При том, что отрабатывает эта штука уже после того, как все линтеры, форматтеры, статические верификаторы и юнит-тесты отработали.
Re[5]: И еще рассуждения об ИИ
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что значит неизвестной заранее структуры ? Ему скармливали код, а он искал в нем дефекты.
Это значит, что никакой специфичной для инструмента разметки нет. Просто даём код, и он ищет в нём любые дефект.
PD>Работал он ЕМНИМ на per- source file основе, поэтому ошибки, размытые между разными файлами, не находил.
А ИИ прекрасно анализирует ошибки, размытые между файлами.
PD>Ну насколько я это понимаю, это можно сформулировать чуть короче. В этот Map добавляются элементы, а this block его не очищает, так что может дело закончиться heap overflow.
Речь о неполной очистке. Когда мы какой-то из объектов разрушили, а соответствующий ему объект из мапы удалить забыли.
PD>Для Java или C# это отловить действительно не так просто. Более того, это может быть неверно. Кто его, этот map знает, может на него еще какая-то ссылка есть извне (не лучшая практика, но и не запрещено), и когда job reaches a terminal status, этим map кто-то и займется совсем в другом месте, и там использует и очистит — через пару интерфейсов и несколько паттернов
Но ИИ нашёл, что нигде в проекте этой очистки нет. И что по логике, которая там присутствует явно в виде документов проекта на естественном языке и неявно — в виде структуры кода, очистку нужно делать именно тут.
PD>Но PVS работал для C++, когда я с ним имел дело, а там все намного проще — есть у этого класса деструктор ("this block"), а в нем не вызывается delete или free для вложенного map. Классический memory leak. Такое он ловить умел.
This block — это не класс. Это просто текст на английском языке: "в этом блоке выполняется очистка задания, достигшего терминального статуса".
PD>https://pvs-studio.com/en/blog/posts/cpp/0543/
Это всё не то. PVS умеет ваш п.5? А это как раз оно — "принять или отвергнуть". Там если он не нашёл, к чему прикопаться, то просто ставит "лайк".
При том, что отрабатывает эта штука уже после того, как все линтеры, форматтеры, статические верификаторы и юнит-тесты отработали.
З.Ы. Важно обратить внимание на формат подачи. Это не просто "правило ES-0051 нарушено в строке такой-то", и сиди разбирайся — то ли это false positive, то ли реальный баг.
А на нормальном, человеческом языке написан комментарий про суть проблемы (в терминах проекта, а не линтера). Ровно так же, как это написал бы мега-внимательный, хорошо разбирающийся в коде проекта ревьювер.
PD>Что значит неизвестной заранее структуры ? Ему скармливали код, а он искал в нем дефекты.
Это значит, что никакой специфичной для инструмента разметки нет. Просто даём код, и он ищет в нём любые дефект.
PD>Работал он ЕМНИМ на per- source file основе, поэтому ошибки, размытые между разными файлами, не находил.
А ИИ прекрасно анализирует ошибки, размытые между файлами.
PD>Ну насколько я это понимаю, это можно сформулировать чуть короче. В этот Map добавляются элементы, а this block его не очищает, так что может дело закончиться heap overflow.
Речь о неполной очистке. Когда мы какой-то из объектов разрушили, а соответствующий ему объект из мапы удалить забыли.
PD>Для Java или C# это отловить действительно не так просто. Более того, это может быть неверно. Кто его, этот map знает, может на него еще какая-то ссылка есть извне (не лучшая практика, но и не запрещено), и когда job reaches a terminal status, этим map кто-то и займется совсем в другом месте, и там использует и очистит — через пару интерфейсов и несколько паттернов
Но ИИ нашёл, что нигде в проекте этой очистки нет. И что по логике, которая там присутствует явно в виде документов проекта на естественном языке и неявно — в виде структуры кода, очистку нужно делать именно тут.
PD>Но PVS работал для C++, когда я с ним имел дело, а там все намного проще — есть у этого класса деструктор ("this block"), а в нем не вызывается delete или free для вложенного map. Классический memory leak. Такое он ловить умел.
This block — это не класс. Это просто текст на английском языке: "в этом блоке выполняется очистка задания, достигшего терминального статуса".
PD>https://pvs-studio.com/en/blog/posts/cpp/0543/
Это всё не то. PVS умеет ваш п.5? А это как раз оно — "принять или отвергнуть". Там если он не нашёл, к чему прикопаться, то просто ставит "лайк".
При том, что отрабатывает эта штука уже после того, как все линтеры, форматтеры, статические верификаторы и юнит-тесты отработали.
З.Ы. Важно обратить внимание на формат подачи. Это не просто "правило ES-0051 нарушено в строке такой-то", и сиди разбирайся — то ли это false positive, то ли реальный баг.
А на нормальном, человеческом языке написан комментарий про суть проблемы (в терминах проекта, а не линтера). Ровно так же, как это написал бы мега-внимательный, хорошо разбирающийся в коде проекта ревьювер.