Ключевые слова:malloc, memory, (найти похожие документы)
- BEST_PEOPLE (2:5077/15.22) ------------------------- BEST_PEOPLE (SU.C_CPP) -
From : Valentin Nechayev 2:5020/400 28 Apr 00 17:57:16
Subj : Null pointer assignment в malloc
-------------------------------------------------------------------------------
* Forwarded from area 'SU.C_CPP'
From: netch@carrier.kiev.ua (Valentin Nechayev)
Hello Dmitry Kapustin!
>> AN>> ptr = malloc( xxx );
>> AN>> *ptr = value;
>> AN>> недопустимо. А тот, кто написал эту программу, так не считает. К
>> AN>> разумным, соответственно, отнесён быть не может. Так,
>> AN>> кнопкодав...
DK> Странный ты человек, Александр. Проще было бы кратко объяснить человеку,
DK> что malloc может вернуть 0, чем делать такие выводы. Да и выводы
DK> неправильные. Одно дело - ты пишешь критический системный компонент,
DK> который должен жить долго не выгружаясь и адекватно реагировать на
DK> недостаток ресурсов в системе. А другое дело - выделить 5 байт в десктопной
DK> программе, которая предназначена для исполнения на машинах с десятками
DK> мегабайт виртуальной памяти... Hу
Для таких ситуаций программа пишется так, чтобы вызывался не malloc, а
какой-нибудь xmalloc (стандартное имя для оного в юниксовом мире).
Код примерно такой:
void* xmalloc( size_t request )
{
void* p = malloc( request );
if( !p ) {
syslog( LOG_CRIT, "xmalloc: request for %lu bytes failed",
(unsigned long) request );
abort();
}
return p;
}
По abort() оно к тому же может испечь корку, в которой через backtrace
можно найти (если это нужно), кто вдруг выжрал память.
(Разумеется, это все еще зависит от принятой в системе схеме распределения
памяти ;) Если это win9* или linux стандартного вида и без rlimit'ов,
то оно упрется в предел памяти, после чего процессы начнут клиниться
(причем не обязательно те, что выжрали память, а скорее те, кто захотели
при этом). FreeBSD начнет отстреливать тех, кто захотел память.
NT как-то достаточно хитро ведет себя. Деталей не помню...)
DK> выполнит некорректную операцию с вероятностью почти 0, ну закроет юзер. Я
DK> вон недавно смотрел DDK для Win2K, там по сравнению с NT 4.0 появились
DK> функции, позволяющие работать без риска вызвать blue screen при нехватке
DK> системных ресурсов.
Hехватка базовых ресурсов - память, открытые файлы, место на диске, процессы -
очень тяжело действует на практически любые программы. Это уже не эхотаг,
но мне кажется правильной тактика демпфирования запросов: при достижении
некоторых рубежных значений - 60, 70, 80, 90 процентов - рассылаются
соответствующие оповещения; 10% ресурса всегда в резерве для системных
нужд (и рута, если юникс).
DK> То есть некоторые функции из DDK валили ядро NT 4.0 (!!!) при
DK> нехватке ресурсов, и ничего, мир еще стоИт. А среди разработчиков ядра NT
DK> не только кнопкодавы, я полагаю. Так что ты перебрал. А для обработки
DK> неудач выделения памяти в десктопной программе лучше использовать механизм
DK> исключений - надоедает каждую аллокацию на 0 проверять. И если не удалась
DK> аллокация - просто сносить задачу, сохранив важные данные.
А как узнать, что является важными данными и как сносить задачу?
Послать exception - это, конечно, было бы лучше всего, но не везде можно.
DK> P.S. Я сам-то скорее педант - стараюсь все тщательно проверять. но другие
DK> имеют право так не делать. И работодатели их понимают.
Тот же xmalloc() прячет проверку, чтобы не надо было вручную каждый раз
писать такие обороты. Hо применяя эту тактику ко всему, а не только к проблемам
памяти, мы придем к тем же C++ exceptions.
... А дальше не сочинилось...
-- --
Valentin Nechayev
netch@carrier.kiev.ua
II:LDXIII/DCCCLXXIII.CCC
--- ifmail v.2.15dev5 * Origin: Lucky Netch Incorporated (2:5020/400)
