Несколько ссылок по программированию

[beldmit]

Using gcc sanitisers to get a nasty bug fixed
К описанным в статье директивам компилятора и линкера должны прилагаться ещё и LD_PRELOAD соответствующих библиотек. Без них ничего не летает.

Differential fuzzing of cryptographic libraries
Вот до практического применения этой методологии у меня руки пока не дошли.

Post-Production Editing using Git
Немного git-овой магии про то, как привести коммиты в человеческий вид постфактум. Кое-что пробовал, но в git я на очень базовом уровне разбираюсь, к сожалению.

Comments

[vitus_wagner]

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

[beldmit]

Я не уверен, что фуззинг - фигня. И openssl team его применяет.

[vitus_wagner]

У меня был один товарищ, который применял fuzzing к catdoc (особенно приколькно это с rtf-ом выглядело) и сейчас у нас активно используется сходная технология - sqlsmith.
Вот на опыте этих двух юзкейсов я делают вывод, что fuzzing-ом надо заниматься только тогда когда любыми другими способами никаких багов найти не удается.

В смысле после того, как обработаны все false positives от статических анализаторов, coverage analysis показывает на нормальном regression test suite минимум пару девяток, и всякие gcc-шные sanitizer-ы в купе с валгриндом рассказывают что у вас идеальный код.

[beldmit]

Фуззинг (описанная библиотека) вроде как бесплатен. Статические анализаторы - отнюдь не всегда.

[yurikhan]

Гитовая статья хорошая. Можно давать джуниорам.

В ней не хватает трёх вещей:

• дисклеймера «я тут демонстрирую всё с командной строки, потому что любимые инструменты у всех разные, но на самом деле файлы редактировать и мёрж-конфликты разрешать надо редактором, а не echo’м и sed’ом; а коммитить каким-нибудь фронтэндом, позволяющим выделять и стейджить отдельные строки (git gui, git-cola, magit, …), а не через git add -p»;
• включить git config --global merge.conflictstyle diff3 прямо сейчас и навсегда;
• всегда смотреть (а не изредка поглядывать) на граф и текущее положение веток, хоть в gitk, хоть в git log --all --graph --decorate --color --oneline --date-order.

И ещё правило не мёржить в постпродакшне устарело с появлением git rebase --rebase-merges.

[phd_ru]

Тихо-тихо ползи
Улитка по коду фуззи

[livelight]

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

В пост-продакшене уже по-любому немного поздно :)

[yurikhan]

Ну вот это «пойди и перекоммить» в статье и называется постпродакшном — приведение отснятого материала в порядок перед тем, как он выйдет на большой экран (будет вмёржен в мастер).

[livelight]

Вон оно чо :)
Я по диагонали прочитал, и потому остался при более общепринятом, АФАИК, в мире софтверной разработки понимании слова "post-production".

А сам я пользуюсь иногда другим инструментом: если джуны долго и мучительно в 100500 итераций коммитили чёрти что, то я ставлю в морде гитлаба у MR галочку squash и прописываю собственный текст для единственного финального коммита. Дальше кому очень хочется почитать историю полёта мысли корявыми путями - может из этого коммита пойти в исходный MR и почитать.