Debian крашит мою программу

Устранил баг. Оказалось, в двух строчках размер текущего токена сохранялся в переменную типа signed char и, разумеется, жёстко обрезался.

Но всё же - как лоровцы ловят такие баги и проверяют работоспособность кода? Больше тестов, проверки всех возможных границ рантайме (с #ifdef конечно же) - вот что пока что использую я. Есть ли смысл поглядеть в сторону статического анализа или есть более хорошие практики?

Но всё же - как лоровцы ловят такие баги и проверяют работоспособность кода?

Хочется верить, что лоровцы не пишут велосипеды. Но, думаю, это далеко не так.

как лоровцы ловят такие баги

Не пользуются питушиным страусиным пометом.

Неужели имеется язык с более богатым набором проверок? Или стиль других языков - фигачить лишь бы работало на 1 тестовом примере и на все проблемы ставить except: pass (или что там для ловли всех исключений)?

Оказалось, в двух строчках размер текущего токена сохранялся в переменную типа signed char и, разумеется, жёстко обрезался.

Но всё же - как лоровцы ловят такие баги

когда у меня будут ТАКИЕ баги, я пойду в дворники. Если возьмут, что вряд-ли...

Гейзенбаг - это баг, который невозможно воспроизвести, так что у тебя точно не гейзенбаг. Твой конкретный баг, анверное, ловится анализом грамматики.

P.S. зачем тебе парсер Python?

неужели пишешь питоновский фронтэнд для llvm?

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

valgrind, etc. По-моему, даже были тулзы для отловли integer overflow, как раз твой случай.

А вообще парсер и анализатор питона лучше писать на чём-нить более подходящим. На питоне или какой-нить bison (каюсь, не шупал).

Пишу парсер для QtCreator, потому и восстановление после ошибок должно быть хорошим. В отличие от C++, в питоне нет точки с запятой и }, до которых можно глотать все токены в режиме паники. Есть токен NEWLINE, но в питоне должно быть неявное склеивание строк, если осталась незакрытая скобка ([{ - а я это как-то забыл учесть при восстановлении.

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

Использую не bison, но qlalr, но он только генерит таблицу LALR парсера и подставляет вместо $rule_number номер последнего описанного правила, остальное ручками; за valgrind спасибо, попробую применить, а то раньше его только как профайлер использовал ;(

гейзенбаг

Я только про Шрединбаг слышал...

По мере написания парсера python

Но зачем, если можно взять готовый питонячий?

Оказалось, в двух строчках размер текущего токена сохранялся в переменную типа signed char и, разумеется, жёстко обрезался.

А предупреждения компилятора для лохов?

как лоровцы ловят такие баги

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

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