Всем привет!
Вопросик простой, но для полноты картины происходящего в компиляторе (или в МК) мне нужно этот вопрос разъяснить. Допустим, есть какая-то функция:


Собственно вопросы:

1. Где необходимо удалять эту переменную result (я имею в виду вызов ф-ции free())? Только в той функции, в которой она была выделена (Multiple()) или же можно сделать это в вызывающей функции по полученному указателю?
2. Я правильно понимаю, что возвращать указатель можно потому, что динамически выделенная переменная помещается в кучу, а не в стек?
3. Как называется область оперативной памяти, которая не отводится под кучу или стек? Как она используется компилятором (что туда "ложится")?

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

ойой
возвращать из функции адрес локальной переменной...

Возвращается адрес блока, выделенного malloc(). Если у ТС есть охота на траблы, почему бы и нет?

да не суть

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

Какие траблы вы имеете ввиду? И как вы себе представляете другое использование кучи?

Именно что суть. Да вы не стесняйтесь, расскажите нам в чем тут ойой. Посмеемся вместе. Над вами.

кучу использую крайне редко
отсюда и у меня некоторое, возможно, непонимание использования оной
то есть malloc просматривает при выделении нужную "дырку", в не зависимости, как и где вызван запрос на область памяти?
посему - free освобождает этот кусок, образуя дырку?
и без разницы где это вызывается?
также, выделяя/освобождая как попало куски памяти, получаем вариант, когда суммарно память свободная есть, а выделить ее не можем, потому как нет одной дырки подходящего размера?


валяйте

Я не про использование кучи - оно вполне естественно, - а про несвязанные явно выделение и освобождение памяти.
Мне больше по душе, когда "выделил - ... - освободил" очевидно (свернув промежуточные {} при необходимости). Мне и своего склероза памяти хватает

Всем спасибо за ответы. Вопрос Сергею: я спросил про "неназванную" область оперативной памяти (которая не куча и не стек) потому что столкнулся с этим при работе в Keil uVision (я пишу под Cortex-M3, хотя это наверное не важно). В стартаповом файле конфигурируется куча и стек. Из доступных 16кБ я под стек выделил 1кБ, а куче ничего, т.к. не использую динамического выделения памяти в этом проекте. Так вот, в программе у меня определены два буфера по 4кБ (как глобальные переменные). Получается, что расположены эти два буфера не в стеке (слишком мал) и не в куче (т.к. они определены статически да и под кучу памяти не выделено). Я, конечно, понимаю, что частично ответил на свой вопрос, но все равно хочется больше информации в этом направлении. Может быть управление оперативной памятью зависит от платформы (компилятора)?

Это стОит того, чтобы ждать!
Так и я пойму даже кое-что про ОЗУ. Хотя, если объем статических переменных ограничен по определению, кучу и стек мы тоже ограничиваем - остальное просто не используется? Тогда хорошо бы что-то (либо кучу либо стек) не ограничивать и использовать на весь оставшийся объем памяти. Просто мысли дилетанта

Существует множество реализаций менеджеров памяти со своими преимуществами и недостатками. Для понимания их работы можно рассмотреть простейший случай. Куча - отдельный зарезервированный участок памяти. При старте - она одна большая "дырка". При вызове malloc() из нее "откусываются" кусочки запрошенного размера плюс еще немного для служебной информации. При вызове free() эти кусочки становятся небольшими "дырками", а если они с какой-либо стороны соприкасаются с другой "дыркой" - то эти две дырки объединяются в одну "дырку" суммарного размера. Таким образом, если освободить все выделенные malloc() переменные - будет снова одна большая "дырка".
Да, естественно. malloc возвращает указатель на "откушенный" участок. Грубо говоря указывать вы можете откуда угодно, пока указываете в это место.
Совершенно верно. Это называется фрагментацией кучи и является главным ее недостатком. Именно из-за нее и стараются не использовать динамические переменные в контроллерах. В основном именно для борьбы с ней и существуют различные менеджеры памяти.
В этой функции не возвращается адрес локальной переменной. Локальная переменная тут одна - result и возвращается ее значение. А вот значение ее является указателем на какую-то точку глобальной кучи (адресом). Так что не ойой, а хихи . Ваш ход.
А, в этом смысле... Ну тогда все объектно-ориентированное придется отменить.
А, понял. Глобальные переменные размещаются в первую очередь. А уже что осталось от ОЗУ после них - отдается под стек и кучу. Ну а что и они не использовали - висит без пользы и вносит вклад в глобальное потепление.
Переменные бывают:
- глобальные ("видны" во всем проекте, хранят значения от старта до завершения программы)
- глобальные статические ("видны" в пределах единицы компиляции, хранят значения от старта до завершения программы)
- локальные статические ("видны" от точки объявления до конца блока, хранят значения от старта до завершения программы)
- локальные автоматические("видны" от точки объявления до конца блока, хранят значения от точки объявления до конца блока).
- динамические (создаются по malloc(), new(), уничтожаются по free(), delete()).
_{вроде бы ничего не забыл.}
Первые три хранятся в памяти в той самой области, которая резервируется под них в первую очередь. И размер этой области линкер может легко подсчитать - это суммарный размер переменных плюс (при необходимости) некоторое количество "пропусков" для выравнивания адресов переменных. Под четвертые память выделяется на стеке в процессе работы. Под пятые память выделяется в куче.
Если стека не хватит - вы узнаете об этом только в процессе работы программы. Ибо расчитать расход стека очень сложно, а иногда и невозможно. Поэтому компилятор/линкер его не считает. Вы резервируете N байт, линкер их размещает. Но ни компилятор, ни линкер не скажут, что этих N байт не хватает для всех ваших локальных автоматических переменных, адресов возврата, контекста прерываний и т.п. Поэтому когда вашим данным не хватит места на стеке, они начнут налезать на данные соседней области - незанятой памяти, кучи, глобальных переменных. Тогда и начнутся чудеса.

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

получается, что информация о куче хранится в какой-то реализации связанного списка там же, в области кучи (ну пока другого варианта не вижу)
отсюда и сложность в использовании оной?

Сергей, спасибо Вам большое. Разжевано предельно понятно Систематизация - полезная штука.

Со стеком имхо ничего не поможет справиться, кроме методов программирования, его минимизирующих. Ограничить стек или не ограничить - все равно если он вылезет за пределы допустимого и налезет на нужную область - то будут действительно чудеса
А в asm нет "статических" и "динамических". Но все asm программисты расписывают имеющееся ОЗУ и сами знают, что им надо хранить от начала и до конца, а какие области можно переписывать в результате промежуточных операций. Си и конкретно менеджеры памяти просто берут эту трудоемкую работу на себя. Но даже на asm есть стек, и при многих уровнях вложенных прерываний он тоже весьма сложно прогнозируется...

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