Статья о небольшой эпопее с поиском ошибки в работе WiFi на плате ESP32-C3 SuperMini, с которой пришлось разбираться в процессе отладки кода прошивки для контроллера батареи АКБ (О контроллере батареи ИБП (вопрос к читателям Хабра) и О контроллере батареи ИБП (часть 2)).

Симптоматика проблемы с WiFi следующая: после включения питания и начала авторизации по WiFi плата ESP32-C3 SuperMini через какое-то время зависает, вплоть до срабатывания сторожевого таймера. Поиск решения проблемы в интернете не помог, но было замечено, что в эти моменты на плате очень сильно нагревается стабилизатор напряжения 3.3V, да так, что даже рука не терпит, тогда как при работе тестовых примеров (где WiFi работает нормально) такого эффекта не наблюдается.

Из-за этого решил копать именно в этом направлении.

Пару лет назад я написал статью "Размышления о структурном программировании", в которой пытался разобраться с заблуждением, будто Эдсгер Дейкстра доказал, что любой алгоритм можно построить всего из трех конструкций (следования, ветвления, цикла).

А вот теперь настало время написать про некоторые проблемы машины Тьюринга - фундаментальной основы всех информационных технологий.

Ошибки при составлении программ для ЭВМ появились даже раньше, чем были придуманы самые первые языки программирования. Собственно, языки программирования и были придуманы как раз для того, чтобы программы писались проще, а количество ошибок в них было как можно меньше.

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

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

Когда копии товаров твоего изготовления начинают продавать под видом оригинальных на маркетплейсах продавцы из Китая, то втайне ты немного доволен. Раз твой товар копируют, значит, он пользуется спросом, и ты все делаешь правильно. Вот только продавцы контрафакта забирают твои же продажи, чем сокращают и так небольшую возможную прибыль, и это если не будет недовольных покупателей. А ведь человек, купивший контрафакт, может поставить минус не только неизвестному продавцу из Китая, но и начать писать негативные отзывы и про оригинальные товары бренда!

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

Данная статья о том, какой многоходовый квест нужно пройти для того, чтобы получить на руки юридически значимую доказательную базу факта нахождения в сети Интернет определенной информации. В моем случае это подтверждение факта продажи контрафактного товара на маркетплейсе, что может потребоваться для возможных будущих судебных разбирательств с продавцом контрафакта или с самим маркетплейсом, если последний будет покрывать подобных недобросовестных продавцов.

Прочитал статью Программисты против вайбкодеров и решил поделиться собственным опытом вайб-кодинга, но уже без рекламы ТГ-каналов и бесполезных цитат авторитетных источников. Пока писал, появилась еще одна статья Революция вайб-кодинга отменяется, но уже с противоположным мнением.

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

Эта статья - подведение итогов небольшого эксперимента (над собой) по использованию вайб-кодинга в С++ проекте, что для программиста с 30-летним стажем работы стало практически вызовом и серьезным выходом из зоны комфорта. Но сейчас все проблемы решены, и в соответствии с Хабрахаком я решил оформить полученные выводы в письменном виде для их систематизации, а заодно и для получения обратной связи.

Считается, что на конференции лучше всего запоминаются первое и последнее выступления. И тут я не являюсь исключением, так как при посещении С++ Zero CostConf 2025 мне сильнее всего запомнились как раз первый и последний доклады, но думаю не только из-за эффекта края, но и по той причине, что они были для меня самыми интересными и именно ради них и я решил съездить в Москву из далекой российской глубинки.

Но мне не хочется писать про само мероприятие, тем более, что видеозапись всех выступлений выложена на сайте конференции C++ Zero Cost Conf 2025 и пересказывать технически детали докладов не имеет смысла.

Однако прошедшее мероприятие было очень необычным и запоминающимся: мне удалось попробовать себя в роли вайб-кодера, а по результатам общения с докладчиками — написать два предложения в комитет по стандартизации C++ от России. Поэтому я всё же решил поделиться с читателями «Хабра» своими впечатлениями от некоторых докладов конференции и собственными выводами о вайб-программировании.

О сколько нам открытий чудных
...

Судя по результатам голосования и комментариям к предыдущей статье, к вопросу контроля АКБ у самых простых ИБП есть некоторый интерес. Данная статья - продолжение данной темы.

Сейчас прототип собран на макетной плате (токовый шунт к которому подключено два АПЦ). Измеритель напряжения и тока INA3221, как рекомендовали в комментариях, я решил не использовать, так как дискретность его измерения 8мВ сравнима с дискретностью 12-ти битного АПЦ в обычном микроконтроллере (для ESP32 получается точность измерения около 6мВ).

Среди ИТ специалистов ходит анекдот, что системные администраторы делятся на 10 категории, на тех кто пока не делает бэкап, и на тех, кто уже делает резервное копирование данных. А так как самой частой причиной отказов в ЦОДах является – сбой электропитания, то обеспечение надежного электрического питания для компьютера (да и для любой другой цифровой техники) является наиглавнейшей задачей.

К сожалению, большинство простых (офисных) источников бесперебойного питания выпускаются либо вообще без возможности дистанционного/автоматизированного контроля его состояния (только звуковое оповещение), либо имеют подключение по USB с собственным протоколом связи и проприетарным приложением, которое обладает самым минимумом функций (наверное маркетологи таким образом ненавязчиво подталкивают потребителей к покупке более дорогих моделей своего оборудования).

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

И особая сложность возникает, когда дома используется сразу несколько бесперебойников, ведь следить за их состоянием приходится самому, тогда как сами устройства не очень дорогие, как правило не имеют возможности дистанционного/автоматизированного контроля его состояния и находятся в разных комнатах.

Некоторое время настрадавшись с подключением UPS по USB с помощью проприетарных программ, я решил разобраться с данной проблемой кардинально - сделать простенький контроллер состояния батареи источника бесперебойного питания со стандартным протоколом связи ИБП, который бы подошел для любого типа и модели источника бесперебойного питания при использования дома или в небольшом офисе.

This article is based on the experience of developing the memsafe library, which, using the Clang plugin, adds safe memory management and invalidation control of reference data types to C++ during source code compilation.

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

Недавно вышла новая версия библиотеки memsafe для языка С++, которая превращает его в Rust с помощью плагина Clang добавляет в С++ безопасное управление динамической памятью и контроль инвалидации ссылочных типов данных во время компиляции приложения.

Но данная статья не о библиотеке, а об особенностях разработки анализатора программы на С++ в виде плагина для Clang.

Можно считать, что это подведение итогов по результатам сравнения нескольких разных способов создания плагина для компилятора С++, а так же очередной Хабрахак для хранения результатов экспериментов и публикации итоговых выводов, которые я решил сохранить не только для себя, но и в виде статьи на Хабре, что бы результатами моего труда могли воспользоваться и другие хорошие люди :-), которым так же может потребоваться погрузиться в дебри парсинга исходного текста программ.

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

Утечки памяти из-за циклических ссылок, это когда два или более объектов напрямую или косвенно ссылаются друг на друга, в результате чего доступная приложению оперативная память постепенно уменьшается, так как ее невозможно освободить автоматически. Они являются наиболее сложными для анализа и в то время как для всех остальных типов ошибок при работе с памятью уже найдены и используются различные решения, например на уровне языка программирования, с помощью сборщиков мусора, проверки заимствований или шаблонов библиотек, то проблема утечек памяти из-за циклических ссылок остается нерешенной и по сей день.

Но мне кажется, что есть очень простой способ устранить циклические ссылки в программе, который можно реализовать практически в любом типизированном языке программирования, конечно, если при этом не использовать все разрешающее ключевое слово unsafe для Rust или оператор reinterpret_cast в случае С++.

The most common types of software bugs are memory management bugs. And very often they lead to the most tragic consequences. There are many types of memory bugs, but the only ones that matter now are memory leaks due to circular references, when two or more objects directly or indirectly refer to each other, causing the RAM available to the application to gradually decrease because it cannot be freed.

Memory leaks due to circular references are the most difficult to analyze, while all other types have been successfully solved for a long time. All other memory bugs can be solved at the programming language level (for example, with garbage collectors, borrow checking or library templates), but the problem of memory leaks due to circular references remains unsolved to this day.

But it seems to me that there is a very simple way to solve the problem of memory leaks due to circular references in a program, which can be implemented in almost any typed programming language, of course, if you do not use the all-permissive keyword unsafe for Rust or std::reinterpret_cast in the case of C++.

Некоторое время назад я попробовал найти формальное доказательство безопасной работы с памятью, которое реализовано в Rust, но так и не смог его найти. После чего у меня сложилось впечатление, что доказательство в формальном виде и вовсе отсутствует, а вся концепция безопасного управления памятью на основе "владения и заимствования" формально не доказана и держится только на честном слове.

Я не являюсь специалистом по Rust, но после просьбы помочь разобраться этим вопросом, был переадресован искать эту очевидную информацию самостоятельно, так как "джентльменам верят на слово". Тогда как косвенным подтверждением моего предположения об отсутствии формального доказательства в общем виде, является тот факт, что отсутствует и полный список разрешающих и/или запрещающих проверок, которые реализованы в самом компиляторе языка.

Я хочу рассказать про изыскания о формальном доказательстве безопасной работы с памятью на основе владения и заимствования (независимо от языка программирования или реализации компилятора), которое основано на собственных данных и рассуждениях.

There have been many discussions about which programming language is better in terms of security and correctness of source code (by "correctness and security" we mean the absence of various errors in the program that manifest themselves at the stage of its execution and lead to the issuance of an incorrect result or unexpected behavior). And some programming languages, such as SPARK or OCaml, were even specially developed to facilitate the proof of program correctness.

Is it possible to write programs without errors at all?

Много копий сломано в обсуждениях, какой язык программирования самый лучший с точки зрения корректности и безопасности (под термином "корректность и безопасность" имеется ввиду отсутствие различных ошибок в программе, которые проявляют себя на стадии её выполнения и приводят к выдаче некорректного результата или неожиданному поведения). А некоторые языки программирования, такие как SPARK или OCaml, даже специально разрабатывались для облегчения доказательства корректности программы.

А возможно ли вообще писать программы без ошибок?

После публикации предыдущей статьи на данную тему, некоторые читатели не обратили внимания, что данный проект, это не действующий инструмент, готовый для боевого применения в реальных проектах, а только доказательство работоспособости концепции использования плагинов компилятора для дополнительного семантического контроля исходного кода С++ во время компиляции. А в качестве примера реализации подобного плагина я взял концепцию безопасной работы с памятью из языка NewLang с минимальной адаптацией под C++.

То есть основная идея предыдущей статьи — продемонстрировать возможность использования плагина компилятора для дополнительного анализатора исходного текста, а не изучение функциональности реализованной библиотеки для работы с памятью (которая и не может быть в полном объеме портирована на С++ из-за архитектурных различий в этих языках программирования).

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

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

Статья в продолжение темы безопасной разработки на С++ с примером работающего кода. Кратко предыдущие тезисы:

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

А раз текущее состояние С++ не может гарантировать безопасную разработку на уровне стандартов, то выходит, что:

• Принятие новых стандартов С++ с изменением лексики для безопасной разработки обязательно нарушат обратную совместимость с существующим легаси кодом.
• Переписать всю имеющуюся кодовую базу С++ под новую безопасную лексику (если бы такие стандартны были приняты),
  ничуть не дешевле, чем переписать этот же код на новом модном языке программирования.

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

Проблема безопасной разработки на С++ возникла не вчера, и она достигла таких размеров, что рекомендации использовать более надежные языки программирования, принимаются на самом высоком уровне.

Но даже несмотря на наличие подобных рекомендаций, планы прекратить использовать С++ и перейти любой другой безопасный язык программирования, часто не выдерживают обычных финансовых расчетов. Ведь если отказаться от С++, то что придется делать с миллионами или даже миллиардами строк кода, которые были написаны за несколько предыдущих десятилетий?

К сожалению, и сам С++ не особо стремится стать более "безопасным". Точнее, подобное стремление плохо сочетается с требования к стандарту языка, которые принимаются комитетом по стандартизации С++. Ведь любой стандарт должен обеспечивать обратную совместимость со всем старым легаси кодом, что автоматически сводит на нет любые попытки внедрения какой либо новой лексики на уровне единого стандарта С++.

И в этой ситуации правы те, кто выступает за обязательную поддержку обратной совместимости со старым кодом. Но правы и те, кто считает необходимым добавление новых возможностей для безопасной разработки на С++ хотя бы в новых проектах.

Таким образом, возникают, казалось бы, взаимоисключающие и не разрешимые противоречия:

• Текущее состояние С++ не может гарантировать безопасную разработку на уровне стандартов языка.
• Принятие новых стандартов С++ с изменением лексики для безопасной разработки обязательно нарушат обратную совместимость с существующим легаси кодом.
• Переписывать всю имеющуюся кодовую базу С++ под новую безопасную лексику (если бы такие стандартны были приняты), ничуть не дешевле, чем переписать этот же код на новом модном языке программирования.

Но ключевым моментом в предыдущем абзаце является фраза "казалось бы".

Еще одна статья в продолжение темы анализа сходных текстов на С/С++ с помощью Clang. Предыдущие публикации:

• ​Как создать собственное расширение компилятора C++
• Анализ AST и рефакторинг кода в Clang

Это не перевод довольно подробной публикации Emitting Diagnostics in Clang от Peter Goldsborough про различные нюансы диагностических инструментов у Clang, а преимущественно адаптация старого кода под текущую версию компилятора.

И основная идея, которая меня заинтересовала в исходной публикации, это использование инструмента FixIt из набора диагностики clang для внесения исправлений в исходные файлы.

В продолжение темы кастомизации компилятора С++ публикую перевод еще одной интересной статьи от Eli Bendersky AST matchers and Clang refactoring tools.

Инструментарий Clang вызывает большой интерес и внимание к разработке в последние годы. Наконец-то у нас есть удобный, точный, с открытым исходным кодом и хорошо поддерживаемый фреймворк для программного анализа и рефакторинга кода C++ и это я нахожу это очень захватывающим!

Прекрасным результатом этого быстрого темпа разработки является то, что постоянно появляются новые API и инструменты.

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