Есть ли потребность проверить на ПУСТОЙ УКАЗАТЕЛЬ после выделения памяти, когда использование ядра превышает возможности памяти
Это - общая практика для проверки на ПУСТОЙ УКАЗАТЕЛЬ (выделяется ли память успешно) после malloc (), некоторая вещь как
void *ptr = malloc(10);
if (ptr != NULL) {
// do some thing usefull
} else {
// no memory. safely return/throw ...
}
с памятью принимают на себя непосильные обязательства, включил в ядре, есть ли шанс получения ПУСТОГО? Я должен применить практику религиозной проверки ПУСТОГО УКАЗАТЕЛЯ для каждого выделения? malloc возвратится, ПУСТОЙ УКАЗАТЕЛЬ inspite агрессивных превышают возможности механизма (я предполагаемое значение 1)?
На самом деле, память использования ядра Android принимает на себя непосильные обязательства (не уверенный в значении, хотел бы знать, это (превысите возможности значения) и его значение). Часть источника платформы (C/C++) код в Android (могла бы быть третья сторона) не проверяет на ПУСТОЙ УКАЗАТЕЛЬ, ни ловит bad_alloc после выделений. Я пропускаю что-то?
Существуют некоторые потоки в ТАК относительно, превышают возможности памяти, но ни один из них не разрешил мой беспорядок.
Править: Если агрессивный примите на себя непосильные обязательства, используется, ПУСТАЯ привычка возвращается (посылка 1). Когда не будет никакой доступной физической памяти и при попытке получить доступ к выделенной памяти (запись в к выделенной памяти), OOM уничтожит некоторый процесс и выделяет память для приложения, пока это не уничтожается в свою очередь (посылка 2). Или в случае я не вижу потребности в проверке ПУСТОГО УКАЗАТЕЛЯ (выделяемая память или в уничтожаемый процесс). действительно ли я прав в своих предположениях?
Мобильность не является беспокойством об этом вопросе.
3 ответа
Да, вам все равно следует проверять ошибки, возвращаемые malloc . В среде с чрезмерным использованием памяти вы не сможете обнаруживать и восстанавливать после сбоев из-за того, что в среде заканчивается физическая память, необходимая при записи в части адресного пространства, которые были выделены вашей программе предыдущим вызовом malloc .
Однако это не единственная проблема, которая может вызвать сбой malloc в традиционной среде. Запрос на особенно большой блок памяти, когда адресное пространство вашей программы стало фрагментированным, может завершиться ошибкой, даже если потенциально достаточно общей физической памяти для удовлетворения запроса. Поскольку не существует непрерывного диапазона свободного адресного пространства , malloc должен завершиться ошибкой. Этот тип сбоя должен сигнализироваться malloc , возвращающим NULL , вне зависимости от того, перегружает ли среда память или нет.
Вы должны проверять возвращаемое значение на NULL каждый раз. Любая библиотечная функция может дать сбой. Даже fclose() (на отключенном NFS ресурсе, а ошибка fclose NFS файла означает, что данные не были сохранены).
Большинство программ плохо написаны и не содержат всех проверок.
malloc не может вернуть что-то кроме NULL или указателя. Все или ничего. Вы не можете получить 1 байт от malloc, если просите 10.
Было бы желательно тщательно проверять NULL во всех вызовах функций, которые могут возвращать NULL, независимо от того, есть ли в ядре избыточное фиксирование память или нет.
В следующем ниже фрагменте кода показано, как проверить, работал ли вызов malloc или нет ...
void *ptr = malloc(10);
if (ptr != NULL){
/* Do something here with ptr */
}else{
/* Do something here if it fails */
}
Операции с файлами, операции с памятью для именования, но некоторые из них возвращают NULL в случае сбоя.
Надеюсь, это поможет, С уважением, Том.