Почему надо проверять malloc на NULL

Дочитай уже.

Там абстрактно говорили, но как раз рабочий и короткий пример для наглядности пришёл в голову.

А как в растишке правильно обрабатывать?

Потому что ты запихал в n адрес переменной b. Затем a[n] эквивалентно *(a+n), то есть ты просто записал по адресу b единицу. А компилятор с -Wall -Wextra ничего не сказал?

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

Ну прибавил ноль к адресу и что?

Ну да, всё так.

Потому что ты запихал в n адрес переменной b.

Специально, чтобы продемонстрировать эффект. Многие, в том числе обсуждаемый Столяров, считают что единственная потенциальная проблема в случайном сегфолте, но это не так.

А компилятор с -Wall -Wextra ничего не сказал?

Ничего. Тем более ничего, если malloc использовать.

но если к нему добавить достаточно большой индекс, то можно испортить какую-то случайную область памяти.

Или не слишком большой, если программа от root'а. Надо как-нибудь будет попытаться извратиться и что-нибудь осмысленное в системе сделать с таким индексом через память процесса.

Ну прибавил ноль к адресу и что?

Захотелось наглядного примера, что отсутствие проверки на NULL - это грязный код. Хотя вот некоторые даже учебники для начинающих пишут, приучая их к подобному стилю (malloc без проверки)

У тебя в коде malloc’а вообще нет. Что ты "проверяешь"-то, прости господи?

А как в растишке правильно обрабатывать?

В раст сделать побитовую запись в произвольный адрес памяти невозможно без ансейф.

Без ансейф можно делать копию, менять байт и записывать обратно - будет безопасно, работать, но уже не то.

Эльбрус рулит. :-)

monk@alatyr:~$ lcc -mptr128 nullptr.c -o nullptr
monk@alatyr:~$ ./nullptr
b = 0, n = 4291371572l
Недопустимая инструкция

У тебя в коде malloc’а вообще нет. Что ты «проверяешь»-то, прости господи?

Какая разница есть или нет? Речь о том, что если указатель равен NULL, что может случиться после вызова malloc, то нельзя надеяться, что программа и так упадёт при первом же разыменовании.

Ну вот тебе с malloc

#include <stdio.h>
#include <stdlib.h>
int main()
{
  unsigned char *a;
  int b = 0;
  
  a = malloc(10000000000000ULL); /* 10 Tb RAM requested */
  if (a==NULL)
  {
     printf("Null pointer!\n");
  }
  
  printf("b = %d\n",b);
  a[(long)&b] = 1;
  printf("b = %d, &b = %llu\n",b,&b);
  return 0;
}

Запуск

Null pointer!
b = 0
b = 1, &b = 140723024629860

Эльбрус рулит. :-)

Отлично. Я так понял за счёт того, что у него указатель не просто число, а со всякими там тегами?

Да. Из одного указателя залезть на другой процессор не даёт.

Недостаток только тот, что на ошибку памяти прилетает не сегфолт, а недопустимая инструкция.

То есть, контролируется, что адрес не залез на чужой участок.

А как там тогда с адресной арифметикой, динамическими массивами, присваиванием одного указателя другому? Например, если нужен указатель, указывающий в середину массива.

P.S. Между прочим, похоже lcc не понимает спецификации %ul

Речь о том, что если указатель равен NULL, что может случиться после вызова malloc, то нельзя надеяться, что программа и так упадёт при первом же разыменовании.

Они не на это надеются. Они рассчитывают, что при обращении по корректному с точки зрения программы, но физически недоступному адресу программа аварийно завершится. То есть они исходят из того, что malloc вообще никогда не вернёт NULL.

Поэтому твои примеры вообще ничего для них не доказывают.

Я тут какую-то фигню с указателями вытворяю, поэтому вы проверяйте маллок. Ну гений!

Эль Брус

Или не слишком большой, если программа от root’а.

А причем здесь от root’а или нет?

Каждый процесс работает в своем изолированном адресном пространстве, и рутовые процессы тоже. То, куда процесс может или не может писать, определяется только тем, какие регионы отмаплены в процесс. У рутовых процессов нет никаких дополнительных мапингов по сравнению с процессами непривилегированных пользователей, от UID это не зависит.

То есть они исходят из того, что malloc вообще никогда не вернёт NULL.

Зря надеются на аварийное завершение, потмоу что, как видно и malloc может вернуть NULL и разыменование нулевого указателя в реальном коде может не привести к ошибке. Есть ulimit. Но и без него если сразу слишком много памяти запросить, то даже при включённом оверкомите будет NULL. В стандартной библиотеке не предусмотрена кросплатформенная функция, чтобы узнать количество доступной памяти, но можно даже сочинить пример поиска бинарным делением допустимого объёма памяти. Как раз с проверкой на NULL в процессе.

#include <stdio.h>
#include <stdlib.h>

int main() {
    /* limits in MB */
    size_t low = 0;
    size_t high = 1024 * 1024; // Searchin within 1TB
    size_t success_mb, mid, mbmid, max = 0;
    const size_t MB = 1024 * 1024;

    printf("Binary search to non NULL max malloc...\n");

    while (low <= high) {
        mid = low + (high - low) / 2;
        mbmid = mid * MB; /* real size to allocate */

        
        void *ptr = malloc(mbmid);

        if (ptr != NULL) {
            /* Succes. Search for more */
            success_mb = mid;
            free(ptr); 
            low = mid + 1; 
        } else {
            // NULL. Lowering limits
            if (mid == 0) break; /* Protection from division by 0 / unreachability */
            high = mid - 1;
        }
    }

    printf("Maximum continuous block: %zu Mb\n", success_mb);
    return 0;
}

Ищет. Хотя, конечно чересчур оптимистично из-за оверкомита:

$ ./binmall 
Binary search to non NULL max malloc...
Maximum continuous block: 64203 Mb

Есть ulimit.

Зачем ты это пишешь?

А как там тогда с адресной арифметикой, динамическими массивами, присваиванием одного указателя другому? Например, если нужен указатель, указывающий в середину массива.

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

P.S. Между прочим, похоже lcc не понимает спецификации %ul

Да. Потому что должен быть %lu (linuxhint.com).

Зачем ты это пишешь?

А чего ты вообще сообщить хочешь?

В конце цепочки ссылок

«в glibc на линуксе malloc всегда возвратит не-NULL»

4.2

Автор как раз и указывает, что если malloc возвратит NULL нельзя полагаться на падение при разыменовании полученного указателя.

А про ulimit написал, так как ты написал, что «исходят из того, что malloc вообще никогда не вернёт NULL».

В конце цепочки ссылок

Это в конце одной цепочки. Вернись на шаг назад и найди конец другой.

Да. Потому что должен быть %lu (linuxhint.com).

Брр, дурацкая ошибка, причём у себя поправил, раз пример запуска корректный был %-)

У рутовых процессов нет никаких дополнительных мапингов по сравнению с процессами непривилегированных пользователей, от UID это не зависит.

Могут права быть на доступ к кодовой секции. В принципе, если с -no-pie компилировать, то адреса секции с кодом получаются короткие (в несколько Мб) и могут оказаться индексом.

Если к адресу прибавить 0, то будет тот же адрес. Вот это открытие.

Пишите еще.

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

Потому что такое понятие как «количество доступной памяти» не имеет смысла.

В тексте каждого сообщения этой цепочки только одна ссылка.

Потому что такое понятие как «количество доступной памяти» не имеет смысла.

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

Другое дело, что нынче даже «количество свободных мест в самолёте» до того, как он взлетел, не имеет смысла, так как продают билетов больше чем мест.

Потому что у тебя многозадачная ОС, это как минимум.

В принципе, этого аргумента достаточно.

В тексте каждого сообщения этой цепочки только одна ссылка.

4.2 же.

В тексте некоторых сообщений этой цепочки две (прописью - две) ссылки.

Права на доступ к кодовой секции определяются битами в заголовке исполняемого файла, или вызовом mprotect().

Ни то, ни другое, от UID никак не зависит.

Это всё понятно. Но интересно другое - а что достопочтенные доны в принципе предлагают делать если malloc() таки вернул NULL? Ну, помимо «поспать и попытаться ещё несколько раз, и если и это не помогло - упасть с диагностикой»?

Development, который мы заслужили.

Один пишет, что выделение памяти проверять не нужно, второй торжественно доказывает, что нужно.

Ну, помимо

Можно не спать. Можно сразу exit.

а что достопочтенные доны в принципе предлагают

Это зависит от ТЗ на код.

Вызывать abort(), что тут ещё делать .

Можно не спать. Можно сразу exit.

Ну, как только мы на это согласились - можно и не проверять, не? :)

Один пишет

второй торжественно доказывает,

Причём, последние 15 лет минимум.

Вносите Царя

можно и не проверять, не?

 Не. 

проверка результата malloc на NULL - зло, по двум причинам

1) malloc это очень частая операция и ты просядешь. Аллокация памяти это больное место всех нынешних прикладов, в динамическую память они влюблены

2) если он таки NULL, то что ? есть разумный план действий без хипа вообще ?? в С++ даже в деструкторах может быть new

тут либо хардверное исключение «памяти реально нет и переключить контекст на заранее сделанный аварийный» (а как это отладить?) или периодично проверять достаточно/нет памяти на перспективу.

Если потом этот указатель индексируется чем-то, что потенциально может иметь большую величину, то лучше проверить.

Потому что теоретически можно например попасть индексом в memory mapped секцию и записать что-то на диск таким образом, испортив файл прежде чем программа упадёт.

Но это отсылает к более широкой проблеме, не к «проверять результат malloc», а к корректности обращения к памяти вообще и тому, что языки с гарантиями безопасности памяти - нужны.

Перехватываем libc’шный malloc(), падаем по ошибкам, и вуаля - клиентам больше проверять ничего не надо. В плюсах для этого new_handler имеется. Все довольны, все смеются. Думаю - все так и делают. Я что-то упускаю?

Я что-то упускаю?

Overcommit. Если можно просто помереть в любой момент любым образом, то можно снять лимиты по памяти и умереть при доступе.

то можно снять лимиты по памяти и умереть при доступе.

В контексте проверок результатов malloc() - какое это имеет значение?

https://docs.gtk.org/glib/func.malloc.html

If the allocation fails (because the system is out of memory), the program is terminated.

Думойте.

Ты точно так же аварийно помрёшь на обращении по адресу, но твой обработчик вообще никогда не выстрелит.

Не знаю, зачем вы меня скастовали. Спасибо r--r--r-- за просвещение населения.

Вместо того, чтобы «в интернете кто-то не прав», покажу следующий фокус: если ты root, можно замаппить нулевой адрес. Тогда при разыменовании NULL на уровне ассемблера не будет сегфолта. Это про «всё равно упадём».

// Compile with:
//      cc -O0 map-zero-page.c -o map-zero-page
// When run as non-root:
//      mmap: Operation not permitted
//      Segmentation fault
// When run as root:
//      (nil)
//      x = 0

#define _GNU_SOURCE
#include <stdlib.h>
#include <stdio.h>
#include <sys/mman.h>

int main() {
    void *ptr = mmap(NULL, 1024, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
    if (ptr == MAP_FAILED) {
        perror("mmap");
    } else {
        printf("%p\n", ptr);
    }
    int x = *(int *) NULL;
    printf("x = %d\n", x);
}

Думойте

Т.е. гномовцы именно это и сделали? Дык, молодцы.

ПыСы. Я не сомневаюсь что при определённой изобретательности систему со включённым overcommit’ом можно поставить раком. Но эти аспекты несколько ортогональны топику «проверять, или не проверять».