On Wed, May 30, 2018 at 04:34:23AM +0300, Leonid Krivoshein wrote:
> 
> 28.05.2018 19:19, Arseny Maslennikov пишет:
> > Пользуясь случаем, всё-таки прошу одобрить таск 206842, исправляющий
> > баги 34347 и 34320. Если код слишком плохой даже для пропагатора,
> > я поправлю, мне не жалко. :)
> 
> Видимо я не спец в нулевых маршрутах, поэтому мало чем могу быть полезен. :)
> Но строчка assert((sz - sp) == 1); вызвала спортивный интерес: как поведёт
> себя приложение с PID=1, если утверждение окажется ложным, с учётом того,
> что в опциях сборки нет NDEBUG.

Как и любое другое, завершится со всеми вытекающими последствиями (я
этим вопросом тоже задался, когда готовил исправление).

С другой стороны, код, в котором такое утверждение под assert() ложно,
содержит логическую ошибку и должен быть исправлен до попадания в сизиф.
Именно так его применяют, например, в (извините) systemd — деймон, который
падает со скрипом, да ещё сообщает место, куда смотреть, лучше, чем
"работающий" деймон с утекающей памятью, или такой, который просто
продолжает творить некоторую известную глупость, в то время как разработчик
не знает горя. Да, даже если это PID 1, в таком случае — тем более.

assert() в нашем случае упрощает тестирование: увидя, что "система
загрузилась" (пропагатор сделал всё необходимое), мы точно знаем, что
определённой глупости не будет, вместо того, чтобы на это надеяться.

> Один не закомментированный assert() в init.c
> есть, это будет второй.
> 

Вообще-то можно было реализовать так, чтобы не нуждаться в дополнительной
проверке.
Коли assert() здесь считают инструментом для слабых духом, я подумал и
решил переписать этот сегмент — тег 20180606-alt1.
Так что пока второго assert() не будет :)