Since I am quoted out of context, I should point out that my proposal 1) to add GNU nested functions to ISO C clearly points out the problem with executable stacks and points out alternative ways to implement them (including having a new function type 2).
Having clarified this, I am not sure it is fair to say that non-executable stack cause vulnerabilities, as they are a mitigation technique and return-oriented programming often defeats it. There are still important though.
The oldest functions-with-data attempt for C (ie compiler people call that closures) was much older, Bruno Haible's callback library. https://savannah.gnu.org/projects/libffcall/
Yet another feature better taken care by using Objective-C or C++ instead.
Eventually it is time to let it be, pretend C is the portable assembler many think it still is, with its security flaws, just like raw Assembly, and use something else for better abstractions and safety.
Since I am quoted out of context, I should point out that my proposal 1) to add GNU nested functions to ISO C clearly points out the problem with executable stacks and points out alternative ways to implement them (including having a new function type 2).
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2661.pdf
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2862.pdf
Having clarified this, I am not sure it is fair to say that non-executable stack cause vulnerabilities, as they are a mitigation technique and return-oriented programming often defeats it. There are still important though.
The oldest functions-with-data attempt for C (ie compiler people call that closures) was much older, Bruno Haible's callback library. https://savannah.gnu.org/projects/libffcall/
Yet another feature better taken care by using Objective-C or C++ instead.
Eventually it is time to let it be, pretend C is the portable assembler many think it still is, with its security flaws, just like raw Assembly, and use something else for better abstractions and safety.