Comdiv писал(а):
adimetrius писал(а):
на второй - надо править компилятор, чтобы, например, BEGIN послеживал за стеком..
Неизвестности со стеком от того, что память на него выделяется по мере роста через восстановление после "page fault". Нельзя ли вклиниться сюда? Тогда не нужно править компилятор
Увы, не только и не столько от этого. Просто НЕТУ системного вызова, который бы отвечал на вопрос: каковы границы стека в данный момент. В разных системах сделано по-разному, и в их мире все пользуются библиотечкой; в ней ifdef на define сидит и undefом погоняет.
Как я понял, там где-то в недрах системы устанавливаются "типовые границы" адресного пространства стека для процесса, и по мере поступления Page fault'ов к этом пространству подключаются новые странички памяти; это делает ядро ОС, а наше ядро даже не подозревает об этом. А вот когда исчерпывается адресное пространство, тогда и прилетает segmentation fault, который ловится в нашем ядре и обрабатывается (на альтернативном стеке - главный-то исчерпан).
Как узнать, какие у моего процесса границы адресного пространства стека - никак; как попросить систему раздвинуть эти границы - не знаю, не нашел. И опять же, у них там есть чудо библиотечка, они ее подключают и не парятся. Теоретически, и нам не возбраняется ее подключить, но я решал задачу в рамках: имеющимися средствами. И, полагаю, она и не нужна нам - бесконечная рекурсия должна умереть на столе разработчика, а для этого достаточно эвристики, которая предотвращает смерть процесса и выдает авост.