Исправления срабатываний статического анализатора.

[Evgeniy Berdnikov]

On Tue, Oct 04, 2022 at 11:33:14PM +0700, Eugene Grosbein wrote:
> 04.10.2022 20:11, Evgeniy Berdnikov пишет:
> >  При потенциальной возможности зануления указателя следует ловить и
> >  обрабатывать такое исключение. В противном случае нет смысла в проверке.
> >  Задача же не в ублажении тупых анализаторов, а в правильной работе кода.
> 
> Как пользователь разнообразного софта, могу доложить, что сегфолт очень фиговая обработка исключений.
> Проверка указателя на NULL перед разадресацией в том случае, когда нельзя гарантировать что он не NULL,
> практически всегда благо.

 Ну, я написал что такую ситуацию нужно ловить всегда, т.е. MUST а не SHOULD.
 
> Другой вопрос, что потом делать, если вдруг: молча восстановиться и ехать дальше,
> или не молча, а с сообщением в лог, или выдать даже stack trace и выйти. Но что угодно лучше сырого сегфолта.

 Был бы я пользователем, я бы тоже так считал, наверное... Но поскольку я
 сисадмин с некоторым запилом в разработку, то думаю иначе: вставить в свою
 софтину полноценный обработчик сегфолта, с анализатором стека и печатью
 регистров, чтобы по функционалу всё было не хуже gdb -- это очень непросто.
 Корпорации размера Оракл могут себе такое позволить, и нанять кучу
 фултайм-саппортеров на разборку трейсов, а для широкой публики нет ничего
 эффективней сборки без стрипа -> coredump -> gdb -> "bt full" и анализа
 содержимого регистров, памяти, etc.

 Конечно, если софтина mission critical, и останавливаться ей никак нельзя,
 то нужно думать об обработке сбоев. Но в большинстве случаев это можно
 решить дизайном: например, при сегфолте в рабочем процессе автоматически
 запускать новый, отмечать сбой в логе / e-mail, а корку оставлять админу
 на изучение.
-- 
 Eugene Berdnikov