Есть ли необходимость проверить на NULL после выделения памяти, когда ядро ​​использует overcommit модуля памяти

Question

Это общая практика для проверки NULL (независимо от того, успешно распределенная памяти) после таНоса(), некоторые вещи, как

void *ptr = malloc(10);  
if (ptr != NULL) { 
    // do some thing usefull 
} else { 
// no memory. safely return/throw ... 
} 

с включенной памятью ядра в ядре, есть ли шанс получить NULL? Должен ли я следовать практике религиозной проверки NULL для каждого распределения? Будет ли malloc возвращать NULL, несмотря на агрессивный механизм overcommit (я думаю, значение 1)?

На самом деле ядро ​​Android использует overcommit памяти (не уверен в значении, хотел бы знать его (превышение значения) и его значение). Некоторый код исходного кода (C/C++) в Android (может быть сторонним) не проверяет наличие NULL и не вылавливает bad_alloc после выделения. Я что-то упускаю?

Есть некоторые темы в SO относительно памяти overcommit, но никто из них не разрешил мое замешательство.

EDIT: Если применяется агрессивный сверхкомпьютер, то NULL не будет возвращен (предположение 1). Когда нет физической памяти и не пытается получить доступ к выделенной памяти (запись в выделенную память), OOM убьет некоторый процесс и распределит память для приложения, пока он не будет убит по очереди (предположение 2). В любом случае я не вижу необходимости в том, чтобы набрать NULL (выделение памяти или удаление процесса). Я прямо в своих предположениях?
Переносимость не вызывает беспокойства по этому вопросу.

Answer 1

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

Однако это не единственная проблема, которая привела бы к отказу malloc в традиционной среде.Запрос на особо большой блок памяти, когда адресное пространство вашей программы стало фрагментированным, может потерпеть неудачу, даже если имеется потенциально достаточная общая физическая память для удовлетворения запроса. Поскольку не существует непрерывного диапазона свободного адресного пространства, malloc должен завершиться ошибкой. Этот тип сбоя должен сигнализироваться malloc, возвращающим NULL, независимо от того, является ли среда чрезмерной памятью.

Answer 2

Вы должны проверить возвращаемое значение для NULL каждые раз. Любая функция библиотеки может выйти из строя. Даже fclose() do (при отключенном общем доступе NFS и ошибке от fclose файла NFS означает, что данные не были сохранены).

Большая часть программного обеспечения плохо написана и не содержит всех проверок.

malloc не может вернуть что-либо, кроме NULL или указателя. Все или ничего. Вы не можете получить 1 байт от malloc, если вы попросили 10.

Answer 3

Было бы полезно проверить наличие NULL в религиозном разрешении по всем вызовам функций, которые могут возвращать NULL, вне зависимости от того, имеет ли ядро ​​перегрузочную память или нет.

Этот следующий сегмент кода ниже показано, как проверить, если вызов malloc работал или нет ... операции

 
void *ptr = malloc(10); 
if (ptr != NULL){ 
    /* Do something here with ptr */ 
}else{ 
    /* Do something here if it fails */ 
} 

файлов, операции с памятью на имя, но мало кто будет возвращать NULL при неудаче.

Надеюсь, это поможет, С уважением, Tom.

Answer 4

Нет, нет необходимости проверять результат работы malloc.

Задолго до того, как malloc потерпит неудачу, операционная система уже столкнулась с множеством проблем.