Возвращение указателя на динамический массив Опции

[Nikitoc]

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

Код

WORD *Multiple (BYTE A, BYTE B){
           WORD *result;
           result = (WORD *)malloc(1);
           *result = A * B;
           return result;
       }

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

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

[Сергей Борщ]

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

Существует множество реализаций менеджеров памяти со своими преимуществами и недостатками. Для понимания их работы можно рассмотреть простейший случай. Куча - отдельный зарезервированный участок памяти. При старте - она одна большая "дырка". При вызове malloc() из нее "откусываются" кусочки запрошенного размера плюс еще немного для служебной информации. При вызове free() эти кусочки становятся небольшими "дырками", а если они с какой-либо стороны соприкасаются с другой "дыркой" - то эти две дырки объединяются в одну "дырку" суммарного размера. Таким образом, если освободить все выделенные malloc() переменные - будет снова одна большая "дырка".

и без разницы где это вызывается?

Да, естественно. malloc возвращает указатель на "откушенный" участок. Грубо говоря указывать вы можете откуда угодно, пока указываете в это место.

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

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

валяйте

В этой функции не возвращается адрес локальной переменной. Локальная переменная тут одна - result и возвращается ее значение. А вот значение ее является указателем на какую-то точку глобальной кучи (адресом). Так что не ойой, а хихи . Ваш ход.

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

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

я спросил про "неназванную" область оперативной памяти (которая не куча и не стек) потому что столкнулся с этим при работе в Keil uVision

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

Получается, что расположены эти два буфера не в стеке

Переменные бывают:
- глобальные ("видны" во всем проекте, хранят значения от старта до завершения программы)
- глобальные статические ("видны" в пределах единицы компиляции, хранят значения от старта до завершения программы)
- локальные статические ("видны" от точки объявления до конца блока, хранят значения от старта до завершения программы)
- локальные автоматические("видны" от точки объявления до конца блока, хранят значения от точки объявления до конца блока).
- динамические (создаются по malloc(), new(), уничтожаются по free(), delete()).
_{вроде бы ничего не забыл.}
Первые три хранятся в памяти в той самой области, которая резервируется под них в первую очередь. И размер этой области линкер может легко подсчитать - это суммарный размер переменных плюс (при необходимости) некоторое количество "пропусков" для выравнивания адресов переменных. Под четвертые память выделяется на стеке в процессе работы. Под пятые память выделяется в куче.

(слишком мал)

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

Тогда хорошо бы что-то (либо кучу либо стек) не ограничивать и использовать на весь оставшийся объем памяти. Просто мысли дилетанта

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