Проясните про malloc

Я тебе на вопросы ответил.

Нет. Ты обосрался. Проясните про malloc (комментарий)

То, что тебе ответы не понравились, не мои проблемы.

Естественно не понравились, потому что ты некомпетентная нулина. И я популярно пояснил почему, на что ты ничего не ответил - т.е. обосрался. Значит твой высер ничего не стоит.

То, что в линуксе может выделиться невалидная память

О боже. Ещё раз, если ты некомпетентная ламерюга, какого хрена ты кукарекаешь о том, в чём нихрена не понимаешь?

Какой нахрен линукс, какая нахрен «выделятся», какая ещё нахрен «невалидная память»? Что ты несёшь?

не означает, что можно пренебрегать проверкой на NULL

Не означает почему. ПОЧЕМУ? Ало.

Ещё может стек закончиться или свет отрубиться

Ну да - чтож стек на null не проверяешь? Своим примером себя же в дерьмо. Как это мило.

Несмотря на все эти сложности проверять на NULL надо.

ПОЧЕМУ? Почему ни одна ламерюга не может ответить на этот простой вопрос, почему? Почему надо? Потому что ламерюга сказала? Или что?

Почему вы все такие тупые?

Разве кто-то из вас может со мною спорить? Вот это новость, ну ничего. Будем считать, что каждый из вас обделался не потому, что балаболящий нуль, а перестал спорить не потому, что балаболящий нуль, а лишь по той причине, что ему «есть чё делать». Ну да. Крайне правдоподобно.

Потому что ламерюга сказала?

А, я понял! НЕ нужно проверять! Так анонимная балаболка, которая, почему-то называет себя царем, сказала! ваистену! У него от этого попаболь и лапша в мозгах, потому что анонимная балаболка «царь» (хотя скорее царевна) ничего дальше локалхоста не видела. Уверуйте, что балаболка что-то знает и воздастся!

О каких именно проблемах идёт речь?

О маскировании проблемы нехватки памяти, когда в процессе обработки программа зависнет, рухнет с другой ошибкой или вообще «молча», или продолжит работать, но некорректно.

Поэтому любой I/O меня уже настораживает, не говоря уже о более развесистых алгоритмах.

Я не говорю, что любой другой путь обработки ситуации ошибочен. Но это как с оптимизацией программы: преждевременная - зло, а если вдруг всё-ж «прижарило», то работать над проблемой должен квалифицированный кадр, причём комплексно, ибо, вполне возможно, не именно в этом месте скрыто решение проблемы.

Где FFT, пидорасина?

О маскировании проблемы нехватки памяти, когда в процессе обработки программа зависнет, рухнет с другой ошибкой или вообще «молча», или продолжит работать, но некорректно.

Вот поэтому и надо проверять результаты malloc-а и адекватно реагировать на них. Как минимум — рухнуть, изложив все проблемы в stderr. А вообще можно и продолжить работать, если уверен в том, что программа и её составляющие работают корректно.

Поэтому любой I/O меня уже настораживает, не говоря уже о более развесистых алгоритмах.

А какие проблемы в I/O могут быть? Очевидно все стандартные функции должны работать нормально, даже если malloc возвращает NULL. Т.е. они могут вернуть ошибку, что не хватило памяти и эту ошибку надо обработать адекватно. Но какой-то порчи буферов и тд быть не должно. В нормально написанном клиентском коде всё будет работать нормально. Например ты пишешь сетевой сервер, обрабатывающий запросы. Не хватило памяти какому-то запросу — верни клиенту индикацию того, что сервер перегружен и надо послать запрос попозже, обработке остальных запросов это не помешает.

Другой вопрос — что при проверке всех выделений памяти код усложняется, это всё обычно никто не тестирует и тд. Поэтому может быть проще тупо брякнуться и построить архитектуру, при которой это нормально. Например на каждый запрос стартует отдельный процесс, упадёт — и фиг с ним. Клиент получит RST и через некоторое время повторит запрос. Так писать проще, но не всегда это возможно.

Очевидно... должны...

Да я уже сам себе не верю, а тут «очевидно», «должны»... :)

В нормально написанном клиентском коде

Сколько процентов такого от всей массы хоть как-то используемых программ?

это всё обычно никто не тестирует и тд.

Я, в общем-то, именно это и имел в виду.

не всегда это возможно

Вот и мне хочется верить, что те, кто собирают и обслуживают самолёты, несколько отличаются квалификацией от сборщиков/ремонтников «бытовой техники». Но разум пытается нагнать ужас «с хрена ли?» :) А уж если речь про СПО «фор фан», то вот тот exit с кодом выхода кажется образцом, а отсутствие обработки результата «маллока» в клиентском коде - далеко не самым плохим решением.

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

Вот поэтому и надо проверять результаты malloc-а и адекватно реагировать на них.

Адекватно реагировать - это не использовать маллок. Нет никакого смысла кукарекать об адепкватных проверках, понимая под проверкой проверку возврата маллока, которая не работает в 99%.

Т.е. типичный школобалабол. Для кукаретинга о «проверка == адекватная обработка» - тебе надо доказать полезность проверки и насколько эта полезность влияет на адекватность. При любой попытке кукарекать на эту тему - ты будешь обосанн, что собственно выше и получилось.

Как минимум — рухнуть, изложив все проблемы в stderr

Каким образом, алёша? У тебя нет памяти.

Либц нихрена не mallocfree, а значит, что ничего не гарантирует того, что оно хоть что-то выведет.

Пока нулям везёт, что тут 8метров стека и алока в гцц во все поля, но вот том, где мало памяти твоя жопа бы разорвалась, но ведь ты только и можешь, что кукарекать. А писать говно, которое работает чисто случайно.

Тем более нахрена кому-то что-то писать? Нулина не может запилить обработчик на сегфолт и затрейсить причину? Ну да, нули они такие.

А вообще можно и продолжить работать, если уверен в том, что программа и её составляющие работают корректно.

Т.е. можно работать на предположении и «уверенности», но подожди. Я уверен в том, что маллок мне не вернёт NULL, а всех ламерков утверждающих обратное я обоссал. Т.е. я точно так же могу не проверять, но ты кукарекаешь, что я должен?

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

Очевидно все стандартные функции должны работать нормально, даже если malloc возвращает NULL.

Очевидно кому, ламерюга? Я тебя удивлю, но стандартные функции могут легально падать, если маллок == NULL. Вперёд - собираешь глибц без С_АЛЛОКА и читать макулатуру.

Т.е. они могут вернуть ошибку, что не хватило памяти и эту ошибку надо обработать адекватно.

Подожди - адекватно - это высрать в stderr, по твоему же высеру. Но если тебе принтф вернул «не хватило памяти», то как ты её обработаешь адекватно?

Но какой-то порчи буферов и тд быть не должно.

Мнение нуля крайне важно для пацанов.

Прям за версту видно эксперта. У тебя зафейлился маллок - тебе надо откатить всё, что было раньше. Какой жопой ты это сделаешь? Я жду куллстори.

В нормально написанном клиентском коде всё будет работать нормально.

Уважаемая ламерюга, как так нормально? Тыж кукарекал, что у тебя там невалидная память. Т.е. память может быть «невалидной» с != NULL, а работает нормально? Ты совсем крякнутый?

И да, сразу завоняло жабашколотрона, который за еду моет полы. Что ты забыл в этой теме?

Например ты пишешь сетевой сервер, обрабатывающий запросы.

Прям ты пишешь? Посмеялся.

Не хватило памяти какому-то запросу — верни клиенту индикацию того, что сервер перегружен и надо послать запрос попозже

Совсем что-ли кря-кря? У тебя нет памяти - как ты вернёшь ему запрос. Куда ты будешь писать ответ? Себе в жопу?

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

Идёшь и берёшь свою жабку - ставишь хуки на аллокатор и смотришь сколько же раз и как он вызвается. Авось хоть тогда до ламерка хоть что-то дойдёт.

Другой вопрос

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

Работающая логика проверки просто не реализована нигде, но почему-то все нули про неё кукарекают.

Подожди - адекватно - это высрать в stderr, по твоему же высеру. Но если тебе принтф вернул «не хватило памяти», то как ты её обработаешь адекватно?

write(2, "Out of memory", xxx);

например так. write в любом UNIX-е будет использовать системный вызов ядра, который скорее всего отработает нормально. Под Windows вероятно надо использовать WriteFile, точно не знаю.

В остальном смысла в твоём посте я не уловил, изъясняйся конкретней.

http://pubs.opengroup.org/onlinepubs/000095399/functions/write.html

[ENOBUFS] Insufficient resources were available in the system to perform the operation.

Почему просто не вызвать abort()?

скорее всего отработает нормально

«Скорее всего» — очень низкий уровень уверенности. Ты должен проверять и этот вызов тоже.

Я сомневаюсь, что в случае терминала или обычных файловых систем можно получить такой код возврата. Понятно, что в общем случае код в ядре может делать что угодно и stderr может быть перенаправлен куда угодно. Впрочем это не важно, суть в том, что если нам надо печатать в условиях нехватки памяти, правильный способ это сделать — использовать write. Остальное уже на совести ядра, на которое влиять невозможно.

Почему просто не вызвать abort()?

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

«Скорее всего» — очень низкий уровень уверенности. Ты должен проверять и этот вызов тоже.

Ну если можно сделать что-то осмысленное, можно и проверить. А что осмысленного можно сделать?

Я сомневаюсь, что в случае терминала или обычных файловых систем можно получить такой код возврата

Докажи. Иначе это балабольство.

for (;;){ p = malloc(4); if (!p) { r = write(...); exit(r); }}

За реру! Царя! и Отечество!