LINUX.ORG.RU

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

 


0

6

Если код будет 100% выполнятся только на linux/freebsd (ну, чисто теоретически, mac, если у меня он когда-нибудь будет чтобы протестировать), то нужно ли проверять возвращаемое значение *alloc функций? Я так понимаю, что на линуксах проверку похерили и оно всегда вернет значение, а потом во время выполнения чего-то важного просто упадет к чертям.

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

P.S. Куда дели теги «си» и «pure c»?


Анонимус выше неистово бушует и в его потоке оскорблений запрятана доля истины. Но ТС определённо заблуждается в этом:

Я так понимаю, что на линуксах проверку похерили и оно всегда вернет значение

На линуксе malloc может вернуть NULL, причём условия не такие уж экзотические, выше уже разъяснили. Что делать с этим знанием на практике — отдельный вопрос.

const86 ★★★★★
()

я что-то не нашел внятного ответа

Я так понимаю, решением вопроса в ТС-а является использование calloc вместо malloc, верно?

reprimand ★★★★★
()
Ответ на: комментарий от Moreo

overcommit

Сам факт наличия overcommit - это баг в ядре. Ненужную память просто не нужно выделять.

P.S. Для fork использовали COW ещё до рождения Торвальдса.

anonymous
()
Ответ на: комментарий от reprimand

Эй! Ну и куда поделись адепты сишки? Или царь? Может таки дадите ответ на вопрос?

reprimand ★★★★★
()
Ответ на: комментарий от anonymous

Так все такм - надо проверять или не надо?

Если вернуло NULL - значит попросил так много памяти что работать нельзя и оно сразу же упадет при попытке писать по *0x00000000.

Если оно вернуло не NULL - нет гарантии, что память в реальности выделилась и работать дальше безопасно. И способа гарантированно узнать это нет.

// Moreo

anonymous
()
Ответ на: комментарий от anonymous

нет гарантии, что память в реальности выделилась и работать дальше безопасно

Это никак не освобождает тебя от необходимости проверять возвращаемое malloc значение.

edigaryev ★★★★★
()
Ответ на: комментарий от anonymous

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

Если оно вернуло не NULL - можно с чистой совестью использовать и падение будет по вине ОС.

anonymous
()
Ответ на: комментарий от anonymous

Если вернуло NULL - значит памяти выделить не получилось.

Это критикал. Предполагаем два варианта:

Вариант 1- ты захотел сожрать очень большой кусок. Большой - в смысле несколько ГБ. Ты знаешь, что это большой кусок, неосознанно такие куски не едят. Значит для тебя не будет сюрпризом, если программа свалится.

Вариант 2- ты захотел маленький кусок (скажем, если в случае какого-нибудь фреймворка - порцию памяти для информации об окне), в пределах 1 МБ. И malloc вернул NULL. Если так получилось - то у тебя физически не хватит памяти пользователю что-то сказать. Я вообще сомневаюсь, что malloc под linux может вернуть NULL на малых блоках.

// Moreo

anonymous
()
Ответ на: комментарий от edigaryev

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

anonymous
()

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

anonymous
()
Ответ на: комментарий от edigaryev

Опять эксперты в треде.

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

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

anonymous
()
Ответ на: комментарий от Legioner

malloc использует системные вызовы для выделения памяти

Очередной эксперт - маллок ничего не использует - использует его реализация, но она к делу не относится. Тем более из этого ничего не следует.

и при нехватке памяти в системе вернёт NULL.

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

anonymous
()
Ответ на: комментарий от anonymous

Сам факт наличия overcommit - это баг в ядре.

Уважаемый нуль, я уже каждой балаболке из вас рассказывал. Оверкоммит и существует для того, чтобы:

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

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

А текущее поведение аллокаторов - это почти чистое поведение, кроме некоторых ограничений, вызванных как раз таки не полным вырубание оверкоммита.

P.S. Для fork использовали COW ещё до рождения Торвальдса.

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

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

anonymous
()
Ответ на: комментарий от anonymous

Так все такм - надо проверять или не надо?

Я уже объяснил - если ты работаешь на абстракциях уровня дефолтного нуля, т.е. пишешь дырявое дерьмо оправдывая свою убогость чем только можно, то нужно.

Если же ты понимаешь что делаешь, то не нужно. В общем случае это не имеет смысла, ибо в тех условиях в которых стабильно работает дефолтное маллок-дермище вернуть NULL может с шансом намного меньшим, чем упасть от криворукости адепта.

Если вернуло NULL - значит попросил так много памяти что работать нельзя и оно сразу же упадет при попытке писать по *0x00000000.

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

Это происки оверкоммита, но ты можешь его спокойно вырубить.

Если оно вернуло не NULL - нет гарантии, что память в реальности выделилась и работать дальше безопасно.

Ну в убогом представлении как-то так.

Шанс на то, что в дефолтном режиме использования малока - тебе вернётся NULL в районе нуля. На мелких кусках до страницы(4к) вернуть NULL оно никак не может, от слова совсем.

«Мелкие куски» «есть всегда», а если нет - оно упадёт внутри маллока.

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

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

И способа гарантированно узнать это нет.

Есть, но маллок и днища к нему никакого отношения не имеют.

anonymous
()
Ответ на: комментарий от anonymous

Если вернуло NULL - значит памяти выделить не получилось.

Я уже вам, нуля 10раз говорил. Перед тем как писать херню - ты должен логически связать вызов маллока и память. Пока ты этого не сделаешь - все твои рассуждения говно.

Нет угрозы сразу упасть, нужно просто меньше кушать.

Опять днище кукарекает о том, в чем нихрена не понимаешь. Куллстори.

Если оно вернуло не NULL - можно с чистой совестью использовать и падение будет по вине ОС.

Типичное днище убогое, птушное пхп-убожество кукарекает.

Если ты ни за что не отвечаешь, ибо заедушная нулина, а раз не отвечаешь, то зачем ты вообще кукарекаешь? Шанс упасть «по вине системы» на порядки выше, чем от сегфолта, а если ты ваяешь убогое дермище, то что даст проверка маллока? Правильно - статистическую погрешность.

Вся суть нулей.

anonymous
()
Ответ на: комментарий от Legioner

Интересно, как fatal печатает форматированную строку в условиях, когда malloc может не работать.

Так там же буфер выделен на старте приложения.

andreyu ★★★★★
()
Ответ на: комментарий от anonymous

Вариант 1- ты захотел сожрать очень большой кусок. Большой - в смысле несколько ГБ. Ты знаешь, что это большой кусок, неосознанно такие куски не едят. Значит для тебя не будет сюрпризом, если программа свалится.

Я писал об этом ниже.

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

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

И тут ты уже рассуждаешь, а какой шанс на то, что ты запросишь больше свободной памяти? Для дефолтных демонов, о которых выше кукарекаели, шанс в районе нуля.

А что мне мешает учесть это самому и исключить такую возможность? А что мне мешает вырубить оверкоммит и прочее.

Вариант 2- ты захотел маленький кусок (скажем, если в случае какого-нибудь фреймворка - порцию памяти для информации об окне), в пределах 1 МБ. И malloc вернул NULL.

1мб - это много. 95%, если не 99% обращений к маллоку - это запросы в районе страницы.

Я вообще сомневаюсь, что malloc под linux может вернуть NULL на малых блоках.

Из твоих рассуждений это никак не выводится - значит ты это где-то прочитал - не понял и пытаешься кукарекать. Зачем?

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

А что мне мешает учесть это самому и исключить такую возможность? А что мне мешает вырубить оверкоммит и прочее.

тебе — ничего. потому что ты можешь писать только для локалхоста :)

anonymous
()
Ответ на: комментарий от anonymous

Вариант 1- ты захотел сожрать очень большой кусок. Большой - в смысле несколько ГБ. Ты знаешь, что это большой кусок, неосознанно такие куски не едят. Значит для тебя не будет сюрпризом, если программа свалится.

Если программа свалится путём сегфолта - это говнокод. Она должна проверить NULL и штатным образом завершиться с каким-нибудь сообщением об ошибке.

Я вообще сомневаюсь, что malloc под linux может вернуть NULL на малых блоках.

Если их миллионы - запросто :-)

anonymous
()
Ответ на: комментарий от anonymous

точнее, ub там возникает даже раньше.

anonymous
()
Ответ на: комментарий от anonymous

ко-ко-ко. Ты мне реально существовавшие до 70-х покажи.

И меня не интересуют твои сливы - на том дермище никак вменяемый ков не реализовать.

anonymous
()
Ответ на: комментарий от anonymous

тебе — ничего

И опять нулёвый балабол обосрался и по-существу ничего не сказал.

потому что ты можешь писать только для локалхоста :)
Маллок
Упало - виновата ОС

не для локалхоста пишет пацан 100%.

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

anonymous
()
Ответ на: комментарий от anonymous

Если программа свалится путём сегфолта - это говнокод.

Сразу видно иксперта по «не локалхостам». Обделался и пытаешься юлить как 5тилетка.

Т.е. если она свалится не путём «сегфолта» - это не говнокод?

Она должна проверить NULL и штатным образом завершиться с каким-нибудь сообщением об ошибке.

Куллстори.

Если их миллионы - запросто :-)

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

Для начала давай смешаем твои «миллионы» - чем миллионы отличаются от не миллионов.

Предположим, что «их миллионы», то какая причина связывает «миллионы» и «вернуть NULL».

anonymous
()
Ответ на: комментарий от anonymous

С реаллоком тот же разговор

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

anonymous
()
Ответ на: комментарий от anonymous

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

Хотя скорее всего ты регистрант с пробитой жопой.

в случае успеха надо старую память освободить

На основании чего ты высрал это утверждение? На основании фантазией из своей пустой, некомпетентной башки?

что может привести к ub

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

anonymous
()
Ответ на: комментарий от anonymous

Типичный представитель вида бабуинус-нулинус.

Вот такие никчёмыши и населяют лор, но ведь они илита, кукарекающая с серьёзным видом и кого уличающая/учащая. Очень показательно.

За все свои годы пребывания на лоре я не увидел ни одного более-менее компетентного балабола. Это болезнь, либо это реальный уровень индустрии? Может быть всё вместе? Да ладно компетенция - тут даже зачатками мозга и минимальными умственными способностями не пахнет. Как можно писать такую херню, как сливаться в каждом своём высере? Как можно не видеть настолько примитивных логических дыр в своём высере.

Почему у этих балаболов способность связывать выводы/утверждения с основание и предметом отсутствует как таковая. «локалхост» «ко-ко-ко» - это на кого рассчитано? На дауна?

Вы все в джунглях росли?

anonymous
()
Ответ на: комментарий от anonymous

Яж тебя левой пяткой с говном смешаю и ты убежишь отсюда в панике.

кококо. ты меня с другими анонами не путай и пили дальше хеллоуворлды на своём локалхосте.

anonymous
()
Ответ на: комментарий от anonymous

какой жопой освобождение памяти может привести к уб?

т.е. ты такое днище что даже этого не знаешь?

anonymous
()

The malloc() and calloc() functions return a pointer to the allocated memory that is suitably aligned for any kind of variable. On error, these functions return NULL. NULL may also be returned by a successful call to malloc() with a size of zero, or by a successful call to calloc() with nmemb or size equal to zero.

В мане написано, что может вернуть NULL, значит надо делать проверку.

omnomnomnus
()
Ответ на: комментарий от anonymous

И опять обосрался. Ну давай, удиви меня. Зачем ты юлишь?

anonymous
()
Ответ на: комментарий от const86

Уважаемый эксперт, теперь запусти свою куллстори на дефолтной тачке. А потом запусти штук 10таких куллстори с лимитами.

В целом тут уже обсёр, ибо данное поведение требует конкретных, не дефолтных условий, при этом даже с ними работает как говно. Нудаладно.

А эти юзкейзы с оверхедом по памяти форфан в 13раз так совместимы с лимита, что прям ахринеть как.

Да и с лимитами он работает не потому, что так должно, а по той причине, что маллок так реализован. Т.е. если бы маллок был реализован с метаинфой не сбоку, а в ином месте(как должно быть у любого вменяемого аллокатора), то оно бы упало и ничего не вернуло.

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

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

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

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

Вот такие сифозные-обосранные бомжи жрущие говно пытаются как-то себя оправдать мытьём рук перед едой. 100% это крайне полезно. Но нули такую херню жрут, а что ещё делать?

anonymous
()
Ответ на: комментарий от omnomnomnus

В мане написано, что может вернуть NULL, значит надо делать проверку.

А теперь вопрос, который разрывает жопу нулей на молекулы.

Написано и? Нахрена конкретно её делать и что она даёт?

anonymous
()
Ответ на: комментарий от anonymous

Нахрена конкретно её делать и что она даёт?

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

Наличие проверки не создаёт проблем. Её отсутсвие может создать проблемы. Этого достаточно.

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

omnomnomnus
()
Ответ на: комментарий от omnomnomnus

откуда такая дикая попаболь по поводу проверки возвращаемого значения NULL

я не в курсе, откуда она у «царя», но меня смущают любые «реакции» на возвращённый NULL кроме 'exit(ERR_MALLOC_FAILED)', ибо где гарантии, что любой другой путь не создаст еще больше проблем сейчас/в будущем, тем более на какой-нибудь экзотической платформе? Иначе это как мёртвому припарки.

Конечно, мы не обсуждаем вопрос использования каких-либо собственных «менеджеров памяти» в надежде, что автор сего будет в курсе - что же он делает :)

yyk ★★★★★
()
Ответ на: комментарий от omnomnomnus

Я тут тебе конечно портянку написал, но так уж и быть не запощу, ибо снесут тему.

Буду краток - ты так и не высрал причин «обязательности проверки». Так же как и не привёл основания для всех своих убогих выводах, аля «есть - надо проверять», «ситуации есть», «частный или не частный».

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

Наличие проверки не создаёт проблем.

Создаёт. Начиная от избыточности и лапши в коде, заканчивая мнимым ощущением безопасности.

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

Её отсутсвие может создать проблемы.

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

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

Этого достаточно.

Ну да, ведь балаболить так просто.

Мне честно говоря интересно, откуда такая дикая попаболь по поводу проверки возвращаемого значения NULL.

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

Хотелось бы помимо анусных молекул от анонимуса услышать какую-нибудь кул-стори по этому поводу.

Ну во-первых я не анонимус. Я не виноват, что обладатели порванных анусов трут моих регистрантов, а всем итак понятно кто я.

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

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

anonymous
()
Ответ на: комментарий от yyk

я не в курсе, откуда она у «царя», но меня смущают любые «реакции» на возвращённый NULL кроме 'exit(ERR_MALLOC_FAILED)', ибо где гарантии, что любой другой путь не создаст еще больше проблем сейчас/в будущем, тем более на какой-нибудь экзотической платформе? Иначе это как мёртвому припарки.

О каких именно проблемах идёт речь? Для C нехватка памяти это нормальная ситуация и с программой ничего страшного не происходит. Просто malloc перестаёт возвращать не-NULL.

Legioner ★★★★★
()
Ответ на: комментарий от yyk

я не в курсе, откуда она у «царя»

У царя попаболь не из-за проверки, а из-за убогих утверждений нулей.

ибо где гарантии, что любой другой путь не создаст еще больше проблем сейчас/в будущем, тем более на какой-нибудь экзотической платформе?

Пойди ещё дальше - даже если там не NULL, то точно так же нет никаких гарантий, что память есть и тебе не прилетит через секунду sigkill.

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

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

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

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

Т.е. с какой угодно стороны проверка абсолютное убожество.

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

anonymous
()
Ответ на: комментарий от Legioner

Балаболка, ты мне на вопросы ответил?

Для C нехватка памяти это нормальная ситуация

Куллстори.

Просто malloc перестаёт возвращать не-NULL.

Прекрасно.

И это кукарекает балаболка, которая выше обосралась на первом же вопросе.

anonymous
()
Ответ на: комментарий от anonymous

Я тебе на вопросы ответил. То, что тебе ответы не понравились, не мои проблемы. То, что в линуксе может выделиться невалидная память, не означает, что можно пренебрегать проверкой на NULL. Ещё может стек закончиться или свет отрубиться. Несмотря на все эти сложности проверять на NULL надо.

Legioner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.