История изменений
Исправление X512, (текущая версия) :
Если выделение памяти произошло, то либо куча, либо стек выросли, но даже если Вы освободите память в случае с кучей через free(), или она сама освободится как в случае со стеком, уменьшения отведённого программе адресного пространства не произойдёт.
Вы говорите про какие-то древние Юниксы в которых куча работает через sbrk. В современных системах куча работает через mmap и адресное пространство освобождается после вызова free, правда не сразу. Есть полно альтернативных библиотек реализации кучи, использовать стандартную кучу никто не заставляет. Языки со сборкой мусора почти всегда делают свою кучу на основе mmap.
Подходя формально, Вам конечно запретить сделать что-то типа mov esp, new_value нельзя.
И на этом весь разговор про системный стек заканчивается. Программа может использовать любую память как стек.
Но вот компилятор скорее всего может неоценить такого подхода и, в случае включённых опций компиляции типа -fstack-protector-strong{all||explicit} не одобрить Ваших действий.
Все эти проблемы решаются. Есть библиотеки короутин которые выделяют стековую память через malloc/mmap и напрямую задают регистр SP. И всё это без проблем работает. Защитную страницу тоже можно сделать через mmap/mprotect.
И не забывайте что языки программирования не ограничиваются C/C++.
Исправление X512, :
Если выделение памяти произошло, то либо куча, либо стек выросли, но даже если Вы освободите память в случае с кучей через free(), или она сама освободится как в случае со стеком, уменьшения отведённого программе адресного пространства не произойдёт.
Вы говорите про какие-то древние Юниксы в которых куча работает через sbrk. В современных системах куча работает через mmap и адресное пространство освобождается после вызова free, правда не сразу. Есть полно альтернативных библиотек реализации кучи, использовать стандартную кучу никто не заставляет. Языки со сборкой мусора почти всегда делают свою кучу на основе mmap.
Подходя формально, Вам конечно запретить сделать что-то типа mov esp, new_value нельзя.
И на этом весь разговор про системный стек заканчивается. Программа может использовать любую память как стек.
Но вот компилятор скорее всего может неоценить такого подхода и, в случае включённых опций компиляции типа -fstack-protector-strong{all||explicit} не одобрить Ваших действий.
Все эти проблемы решаются. Есть библиотеки короутин которые выделяют стековую память через malloc/mmap и напрямую задают регистр SP. И всё это без проблем работает. Защитную страницу тоже можно сделать через mmap/mprotect.
Исходная версия X512, :
Если выделение памяти произошло, то либо куча, либо стек выросли, но даже если Вы освободите память в случае с кучей через free(), или она сама освободится как в случае со стеком, уменьшения отведённого программе адресного пространства не произойдёт.
Вы говорите про какие-то древние Юниксы в которых куча работает через sbrk. В современных системах куча работает через mmap и адресное пространство освобождается после вызова free, правда не сразу. Есть полно альтернативных библиотек реализации кучи, использовать стандартную кучу никто не заставляет. Языки со сборкой мусора почти всегда делают свою кучу на основе mmap.
Подходя формально, Вам конечно запретить сделать что-то типа mov esp, new_value нельзя.
И на этом весь разговор про системный стек заканчивается. Программа может использовать любую память как стек.
Но вот компилятор скорее всего может неоценить такого подхода и, в случае включённых опций компиляции типа -fstack-protector-strong{all||explicit} не одобрить Ваших действий.
Все эти проблемы решаются. Есть библиотеки короутин которые выделяют стековую память через malloc/mmap и напрямую задают регистр SP. И всё это без проблем работает.