Comments 17
Могут быть потеряны данные, которые считались много часов
И тут вспоминаются пакеты типа OpenFOAM, которые при нехватке памяти падают с сегфолтом.
Термин «ответвенный код» в переводе «responsible code» там не употребляем (погуглите — даст «код» в значении правило). Например, фраза «использование strdub() — безответственно» у нас будет иметь смысл в силу культурологических особенностей. А там — нет. А как быть если целые проекты имеются на базе strdub? Вполне успешные, даже с утечками памяти.
Потому поднятый вами вопрос относится в области требований конкретного проекта, а не поведения программиста в целом. А писать в данном аспекте стоит о характеристиках типа fault-tolerance /отказоустойчивость или robustness /живучесть.
В библиотеках нельзя вызвать функцию exit, если не удалось выделить память. По этой же причине нельзя использовать xmalloc. Для многих приложений недопустимо просто взять и аварийно завершить их работу.
Не соглашусь. Именно так происходит в языках с исключениями, и это правильно. Если разработчик приложения, не проверив, что память выделилась, что-то пытается с ней делать, то это кривое приложение и лучшее, что оно может сделать — завершиться, прежде чем разломает какую-нибудь базу неправильными данными.
Но это в языках с исключениями, не знаю, как это поведение реализовать в Си. То, что вы предложили — возвращать код ошибки — тоже плохо и ненадежно, так как нет гарантий, что кто-то будет результат функции проверять. И ошибка просто останется незамеченной и выскочит на более позднем этапе, когда например при подготовке годового отчета выяснится, что в базе за год одни нули вместо данных. И теперь "компьютерщику" надо их как-то восстановить. В языках с исключениями такой проблемы нету.
Для многих приложений недопустимо просто взять и аварийно завершить их работу. Из-за этого, например, может быть испорчена база данных. Могут быть потеряны данные, которые считались много часов.
Это очень ненадежный подход, так как программу может прибить по куче других причин (OOM киллер, злой админ, отключение питания). Хорошие программы сохраняют данные и переживают аварийное завершение.
Вы понимаете, что функция exit и исключения это совершенно разное?
То, что вы предложили — возвращать код ошибки — тоже плохо и ненадежно, так как нет гарантий, что кто-то будет результат функции проверять.
https://habr.com/ru/post/324642/ — это стандарт же
Аналогично нет никаких гарантий что исключение не проглотят.
Ещё раз. Я не прошу и не требую, что каждая программа обязана обрабатывать ситуации нехватки памяти :). Хотя и считаю отсутствие обработки плохим тоном.
Я настаиваю на позиции, что что библиотека не имеет права решать за других, что нехватка программы == прекращение работы. Библиотека должна вернуть статус ошибки/сгенерировать исключение. А как уже поступить с этой информацией, решать приложению.
Я настаиваю на позиции, что что библиотека не имеет права решать за другихЗолотые слова.
Есть разница между «не иметь возможности» и «не иметь желания» %)
Полностью согласен с тем, что сама программа должна решать что делать с ошибкой. Задача библиотеки ошибку донести, а не убиться об неё.
По поводу malloc хочется передать пламенный привет libimagemagick. Там, конечно, исторически сложилось (сначала была cli-утилита, а уже потом из нее сделана библиотека), но это не повод чуть что сегфолтиться и оставлять за собой гигабайты временных файлов.
Шестая проверка Chromium, послесловие