Что корректный путь состоит в том, чтобы обработать “из памяти”?

Следуйте стандартизированному API

Даже в Linux можно использовать ulimit для получения быстрого возврата ошибки malloc. Просто по умолчанию установлено безлимитное.

Существует определенное давление, чтобы соответствовать опубликованным стандартам. В большинстве систем, в конечном итоге и даже в Linux, malloc (3) вернет правильное указание на сбой. Верно, что настольные системы имеют виртуальную память и требуют подкачки, но даже в этом случае отсутствие проверки malloc (3) работает только в отлаженной программе без утечек памяти. Если что-то пойдет не так, кто-то захочет установить ulimit и отследить его. Внезапно проверка malloc обретает смысл.

Использование результата malloc без проверки на null недопустимо в коде, который может быть открыт для использования на платформах, где malloc может дать сбой, на тех, где это приведет к сбоям и непредсказуемому поведению. Я не могу предвидеть будущее, не знаю, куда пойдет мой код, поэтому я бы написал код с проверками для malloc, возвращающего null - лучше умереть, чем вести себя непредсказуемо!

Стратегии того, что делать, если malloc не работает, зависят от вид применения и степень вашего доверия к библиотекам, которые вы используете. В некоторых ситуациях единственное безопасное решение - это остановить всю программу.

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

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

Но во многих случаях единственный разумный способ отреагировать на сбой malloc - это завершив программу. Этого можно добиться, если позволить вашему коду просто рухнуть из-за неизбежного нулевого разыменования. Конечно, всегда было бы лучше выгрузить запись журнала или сообщение об ошибке, объясняющее ошибку, но в реальном мире мы работаем по ограниченному графику. Иногда окупаемость вложений в педантичную обработку ошибок отсутствует.

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

Зависит от приложения, которое вы пишете. Конечно, вам всегда нужно проверять возвращаемое значение malloc (). Однако изящная обработка OOM имеет смысл только в очень редких случаях, например, при низкоуровневых критических системных службах или при написании библиотеки, которая может быть ими использована. Следовательно, наличие оболочки malloc, которая прерывается при OOM, очень распространено во многих приложениях и фреймворках. Часто эти оболочки называются xmalloc () или аналогичными.

GLib g_malloc () также прерывается.

Если вы собираетесь обрабатывать огромное количество памяти, и хотите сделать для Linux такие утверждения, как «теперь у меня есть область памяти ABC, и мне не нужна часть B, делайте, как хотите», взгляните на семейство функций mmap () / madvise (), доступных на складе Библиотека GNU C. В зависимости от ваших шаблонов использования код может оказаться даже проще, чем использование malloc. Этот API также можно использовать, чтобы помочь Linux не тратить память на кеширование файлов, которые вы собираетесь читать / писать только один раз.

Они хорошо задокументированы в документации GNU libc info.