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