Годная реализация malloc-памяти как внешней стековой.

Apache Portable Runtime?

apr_pool_t

http://apr.apache.org/docs/apr/2.0/group__apr__pools.html

Ну как минимум можно взять любой менеджер памяти, который не прибит гвоздями к syscall'ом и менеджерить с его помощью память внутри большого массива-локальной переменной. А вот с выделением новой будут проблемы. Ты как это вообще себе представляешь? Стек это на то и стек, что в него нельзя по-нормальному посередине вставить что-то. А между тем после локальных переменных main в стеке будут адреса возвратов и локальные переменные функций, которые она вызвала из себя.

Но вообще зачем всё это?

Тысячи их, хоть тот же dlmalloc.

на стеке

Wut?

выделяется на стеке достаточное место что бы затем раздавать остальной программе

тебе для embedded что ли?

есть(нужна такая что) функция прокладка которая выделяет на стеке сотнинефти а затем все остальные из под неё запущенные получают посредством malloc-ов указатели на нефти.

Какой-то embedded? Переполнение стека схватить не боишься?

размер стека должен быть известен до старта программы

сильное допущение.

1. скорее контролируемое окружение.

2. зачем?

функция прокладка

Я стесняюсь спросить, что это.

на стеке сотнинефти

Ты переполнение стека хочешь или что?

зачем всё это

пирформанс

1. скорее контролируемое окружение.

Зачем тогда стек? Выдели себе кусок памяти mmap'ом и спи спокойно.

стек сущность языка&машины (и где то там за кулисами mmu проца и хитрые трюки управления физическими страницами)

mmap - это сущьность язык&OS и их разделения сервисов на.

зы. выше язык==C, OS=.*ix

как правило вставлять не надо ибо на стеке зарезервированно достаточно(да если оценка оказалась ошибочна следует имеет механизм увеличения)

стек сущность языка

Да сейчас. В стандарте C даже слова такого не встречается.

1. обычн main(и предшестующее ей настройка окружения-сервисов) из main -prog()

1.1 main{... call mymm(... настройка call prog(здесь вызовы к «своим-mymm» malloc|free ))

2.стек достаточно многобайтный -его хватит.

auto vs static

А если сделать баальшой глобальный массив, его не хватит?
Я полагаю, что в играх типа quake, особенно при запуске без ОС под dos так и было. Сейчас реализации zone memory используют malloc или что-то похожее

1. скорее контролируемое окружение.

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

блекджек со шлюхами творится через malloc_hook free_hook и произвольно взятый ститический аллокатор.

char *sotni_nefti;
void make_hooks() {
  __malloc_hook=alloc_from_sotni_nefti;
  __free_hook=free_to_sotni_nefti;
}

void (*__malloc_initialize_hook) (void) = make_hooks;

int main() {
  char sotni_nefti_d[100500];
  sotni_nefti=sotni_nefti_d;
  ....
  /// теперь ошибки по памяти, заодно херачат стек
}

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

Вот интересно, есть ли такое для разделяемой памяти, да ещё чтобы проект не был брошен.