# Притча о нулевом указателе для ленивых C программистов

Я согласен, что ошибка выделения памяти с помощью malloc редкая ситуация, и после такой ошибки, скорее всего, невозможно полноценное функционирование программы\. Но меня удивляет, с каким упорством программисты, приводя эти аргументы, предлагают вообще ничего не делать в такой ситуации\. Я не призываю всех делать сложные механизмы восстановления работы после нехватки памяти или использовать заранее выделенные резервные буферы\. Многим программам не нужны такие сложные механизмы\. Тем не менее я не понимаю, почему хотя бы минимально не обработать такие ситуации корректно\. Раз других объяснений пока не хватило, попробую в этот раз рассказать короткую притчу\.

![1107_The_parable_of_null_pointers_ru/image1.png](https://import.viva64.com/docx/blog/1107_The_parable_of_null_pointers_ru/image1.png)

Эта статья является расширенным комментарием для дискуссий на некоторых площадках\. Поэтому если вы не в контексте, то предварительно отсылаю вас к этим двум публикациям:

* [Четыре причины проверять, что вернула функция malloc](https://pvs-studio.ru/ru/blog/posts/cpp/0938/)
* [Почему проверять результат вызова malloc c помощью assert плохая идея](https://pvs-studio.ru/ru/blog/posts/cpp/1104/)

**Притча**

Жила\-была компания, занимающаяся разработкой программного обеспечения\. Был у них большой клиент, который платил много денег и всё было хорошо\. Но потом этот клиент начал жаловаться, что у некоторых пользователей приложения начали падать\.

Почему падает вроде понятно — разыменование нулевого указателя\. Понятно, да непонятно, так как разработчики не могут у себя проблему воспроизвести\. Да ещё и клиент с приватными данными работает\. Не пришлёт он тебе ни стектрейс, ни дамп, не позволит провести сеанс удалённой отладки\.

Клиент же тем делом всё больше раздражается\. Делать что\-то надо\. Отправляет компания разработчиков с исходниками и отладочными версиями в офис заказчика\. Чтобы те баг искали под присмотром и в закрытом контуре\.

Дорогое это удовольствие, так команду отвлекать, тем более что ехать нужно было в другую страну\.

Нашли они баг\. На некоторых 32\-битных Windows машинах памяти мало было, или файл подкачки был маленький\. Не хватало памяти иногда\. Функция выделения памяти _malloc_ возвращала _NULL_\. Нулевой указатель разыменовывался, и программа падала\.

Так почему было так сложно всё это сразу понять? А потому, что команда программистов ленивая была и не проверяла, что функция _malloc_ возвращает\. Думали, что раз памяти нет, то всё равно сделать ничего нельзя\. Пусть программа падает\. Она и падала с сообщением про нулевой указатель\.

Программа как минимум могла бы напечатать "Out of memory"\. Это сократило бы время на исследование\. Команду бы не пришлось никуда отправлять, а можно было бы быстро выяснить, что за характеристики и настройки у машин, на которых такое происходит\. Да ещё бы и клиент более доволен был качеством программного обеспечения\.

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

**Мораль**

Не ленитесь\. Обработайте указатель, который вернула функция _malloc_ \(_realloc_, _calloc_, _strdup_ и т\.д\.\)\. Да, проверка может не пригодиться на практике\. Возможно, памяти всегда будет достаточно\. Но что, вам жалко, что ли? Пишите надёжный код\. Не будьте как те программисты из притчи\.