Да, схванах, за другото писах.
За да може да се сложи някаква проверка ще трябва да се знае колко ще трябва за следващия поне. Това като информация трябва да се извади с някакъв анализ на кода предварително - статичен чек или нещо проиграващо.
Аз си мисля дали не е възможно да се направи още по време на билда - знаят се ентри поинтовете (ексепшън векторите примерно вкл. ресет) и се гледа кой какво вика насетне. На същия принцип работи garbage collector-а на линкера на гцц-то. Оттам трябва да се хванат всички консумирания от стека. разните локални променливи и подобни да кажем са лесни, на както Миро каза въпросът е как да се хванат разни функционални пойнтъри за колбеци и т.н. То в по-сейфти системите функционалните поинтъри са задължително константи. Но при фриволно ползване не е така.
И тука е въпросът заслужава ли си мъката - явно за повечето от нас не е обосновано - оставяме да гръмне и събираме останките да си извадим изводи.
Какво е нужно за да се заобиколят тия пречки - дали езикът (c++ 11+)има достатъчно потенциал по-специално с разширенията за async-await че да не се минава през свободни функционални пойнтъри, или по-точно да се прави dependency injection за разкуплиране на отделните части, или си иска принципно друг подход за описване на идеята, за да може да не се загубва тая информация.
Имам предвид че ако се дефинира целта "компилаторът/линкерът/пост-инструмент да извежда грешка при възможен стек овърфлоу" е ли постижимо? И къде ще бъде балансът между фалшиви позитивни и негативни сработвания?
При по-свестните езици изразителността е по-висока и е далеч по-лесно да се разбере кое какво вика, за да се изградят възможните нишки в изпълнението и да се почне да се трупа коя нишка колко стек ще засмуче. Може ли да се дефинира набор от C/C++ конструкции, които усложняват или са директно невъзможни за проследимост статично, билд тайм?

Точно тук е заровен ключа за бараката - компилатора знае всяка функция колко стек ползва (1) и го заделя в стека. Също така се знае всяка нишка с колко стек е създадена (2) а от текущият указател на стека се изчислява колко точно е зает (3). Всичката тази информация се знае рънтайм в пролога на функцията още преди да е заделен стека и да е омазано каквото и да е и просто се проверява дали (1)+(3)>(2) - тази функционалност я имаше още в 16 битовите компилатори за MS-DOS в края на 80-те - после с добавянето на мегабайти и гигабайти памет постепенно спря да се ползва, но отдолу компилаторите би трябвало все още да си я поддържат.

Ц++ може всичко като Ц. Може и още. Програмистите избират, как да използват възможностите - дали за добро или за лошо
Специално последните версии 11++ до 18++ се развиват в посока шаблони, което в някои отношения може да е за добро, но в светлината на тая тема изобщо не е толкова добре. Предвидимостта що за код ще се генерира след специализация на шаблоните не е нулева, а по-скоро отрицателна.

Абе не е баш така - за всяка функция е ясно точно колко стек би използвала (изключваме динамично алокиране на променливи в стека), така че проблемът е само когато има не опашна рекурсия - във всички останали случаи стека е изчислим и в дълбочина.

Става въпрос, че като пишеш шаблон идея си нямаш как ще се компилира. Аз така се бях запалил, тръгнах да портвам STL-a, но то в началото няма как да тестваш и чак като го докарах до половината и взех да компилирам разбрах, че съм си загубил времето. Нямаш никакъв контрол, едно и също нещо веднъж се компилира добре, друг път ужасно. Ако се е компилирало добре пък дебъгера не се ориенира. Изгубих страшно много време, но резултатът не ми хареса и сега само си стои като паметник в репото.
Не знам сега може да са оправили малко gcc-то, но преди няколко години работеше само колкото да се каже че работи с шаблони. Но дори и да работи, т.е. да не бълва излишен код, ти пак няма как да имаш идея за стека. Примерно алгоритъм някакъв. Да кажем сортировка. Ти го пишеш абстракнтно, слагаш вариации в зависимост от това какво може да е. Но в крайна сметка ти работиш с абстракция, не знаеш какво сортираш - ябълки ли, круши ли или звездите в небето. Ако компилаторът е добър и данните налични, стига да си спазил определени правила сортировката може да стане по време на компилация и да няма рън код изобщо.

При всички случаи накрая имаш генерирана функция с машинен код в която дълбочината на стека е прецизно изчислена от компилатора за да събере всички локални променливи - като няма никакво значение какви абстракции и алгоритми ползваш, нито пък шаблони, оптимизации, инлайнати функции и т.н.

Между другото от преди 2-3 години в gcc вече стабилно работи link time optimisation - което си е качествен скок в оптимизирането и много от проблемите които си забелязвал с кофти код са решени. Имаше един пич от мозила който тества ефекта на компилаторските оптимизации върху фирефокс и пише в един блог разни хитринки ... не мога да го отркия в момента, по късно ако ми остане време ще го разровя - струва си да го прегледа човек.

Едит: открих го ... http://hubicka.blogspot.com/2018/12/fir ... clang.html

да де, той компилатора си знае, даже може и да показва колко е стек usage-a за всяка функция локално. Но без виканите пак не може да се определи нужния стек за всяка нишка. И пак стигаме до определяне "на око", само че при шаблоните очите мноооого лъжат

Иначе аз наскоро минах от gcc 6 на gcc 8, видимо има разлики. Най-малкото на определени сорсове доста повече се замисля. Не съм задълбавал като код какви ги върши, но забелязах леко набъбване в размера на изходните файлове. Може и да е дебъг информация, както казах не съм задълбавал.