Если вы пишете код на языке C или C++, поиск и устранение ошибок работы с памятью, таких, как утечки, выход за границы массива или обращение к неинициализированной памяти, могут доставить немало хлопот. Существует по крайней мере два инструмента для решения этих проблем — Valgrind (не путать с Vagrant!) и Clang’овский MemorySanitizer. Последний работает исключительно под Linux и показал себя несколько сырым и не слишком гибким инструментом, поэтому поговорим о Valgrind. Он довольно гибок и работает везде. Кроме того, в отличие от MemorySanitizer, Valgrind может находить неинициализированные данные с точностью до одного бита. Из недостатков Valgrind стоит отметить сравнительно низкую скорость работы.

Продолжая серию постов о полезных библиотеках в мире C/C++, стоило бы упомянуть хотя бы одну библиотеку для сжатия данных. Библиотек таких великое множество. Среди них, пожалуй, наиболее распространенной, своего рода стандартом де-факто, является zlib. Поэтому о ней далее речь и пойдет.

Нет причин не продолжить наше с вами изучение библиотек для языка C. Ранее в этом блоге рассматривались библиотеки libcurl, libpcap, а также некоторые сильно менее распространенные. Сегодня же мы узнаем, как программы на C могут работать с реляционными базами данных.

Рассмотрим типичную задачу. Есть программа на C или C++ с исходниками. Известно, что при выполнении определенных условий программа начинает отжирать слишком много памяти. Нужно понять, почему это происходит, и по возможности исправить. Инструменты, которые мы рассматривали до этого, например, в заметке Профилирование кода на C/C++ в Linux и FreeBSD, для этого явно не подходят. Спрашивается, что же тогда делать? На помощь приходит Heaptrack!

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

Иногда при отладке программы бывает удобно посмотреть, что она передает по сети. Для решения этой задачи существует множество программ-снифферов. Проблема в том, что иногда они бывают не совсем удобны. Так, tcpdump всегда выводит IP- и TCP-заголовки пакетов, а мне они не всегда интересны. Этого недостатка лишен tcpflow, однако он не работает с UDP и имеет больно уж широкий вывод в консоль. Столкнувшись со всем этим в очередной раз, я решил написать наконец свой маленький основанный на libpcap сниффер, который был бы удобен лично мне. Как оказалось, пишутся такие снифферы очень просто.

Ранее в заметке Профилирование кода на C/C++ в Linux и FreeBSD вскользь упоминалось, что аналогом perf из мира Linux во FreeBSD является утилита pmcstat. Однако не сообщалось, как именно этим pmcstat пользоваться, просто потому что на тот момент я этого и не умел. Не так давно, благодаря помощи со стороны Федора Сигаева, мне все-таки удалось осилить pmcstat. А теперь, благодаря помощи с моей стороны, осилить удастся и вам!

Поговорим о системах сборки, а конкретнее — одной из них, Autotools (также известной под названием GNU Build System). Если вы когда-нибудь собирали программу при помощи волшебной последовательности команд ./configure && make && sudo make install, значит вы использовали Autotools. Откровенно говоря, в новых проектах я бы рекомендовал использовать CMake, ну или хотя бы SCons. Но по историческим причинам многие проекты все еще используют Autotools. Также некоторые люди ошибочно считают Autotools чем-то типа стандарта де-факто. А значит, было бы неплохо примерно понимать, как им пользоваться.

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

Те-еретики часто критикуют язык C за то, что якобы в нем все ну очень плохо с контейнерами, и было бы здорово иметь в языке какой-то аналог STL. Мол, либо приходится все хранить по указателям, либо писать свой кодогенератор на Python, что-то в таком духе. Сегодня мы убедимся, что все это неправда.