A Rebuttal of an Article Involving Executable Memory

This article was spurred by ``Infectious Executable Stacks'' which may be found here:
https://nullprogram.com/blog/2019/11/15

Also referenced are the following:
https://nullprogram.com/blog/2019/10/27
https://nullprogram.com/blog/2018/07/20
https://nullprogram.com/blog/2018/11/21

The author of the article being rebutted begins by decrying an unnecessarily complicated thread edge
case, variable-length arrays, and memory aliasing in the context of C.  In order: this is due to the
poor POSIX semantics regarding the failure of system calls, which can occur for most any reason, and
the insufficient signal mechanism, combined with how the C lacks anything resembling the Common Lisp
UNWIND-PROTECT; the issue with variable-length arrays is, as with many other things, that C performs
no safety checks of any kind and also lacks anything resembling a memory exhaustion exception, along
with any exception system at all; and the issues with memory aliasing come from C both requiring the
overuse of pointers and requiring most variables have addresses, unlike Ada.  Simply put, the author
has written several articles concerning how C is supposedly efficient and simple, despite knowing of
all of these grotesque and bizarre misfeatures and pitfalls laying about.

Moving on, the article being rebutted concerns memory which is both writeable and executable and how
this is supposedly a bad thing.  Apparently, GNU C implements its nested functions extension using a
stack trick which requires the stack memory to be executable; this is considered bad due to how easy
the C language makes catastrophic program failure.  The author continues, to deem this default being
a ``fail open design'' and how he failed to notice this for years in one of his programs.

I can easily envision a design of closures that doesn't require the stack trick, but can only figure
this is imposed by some constraint regarding the compiled output and also how C isn't built for such
simple features as closures.  In any case, a program which suffers memory errors is horribly broken,
regardless of whether that memory is or isn't also executable.  That this would seriously be used as
a security feature intended to prevent nigh-inevitable memory errors from becoming worse, as opposed
to an optional layer of a security system, is a general indictment of C.  Further, the impact of the
restrictions imposed severely disadvantage programs which generate machine code as they execute, but
this is usually dismissed as being uncommon.

In closing, I consider such restrictions a good example of the C attitude of, rather than aiming for
a correct program, taking great effort to add layers of defense that are still trivially bypassed by
a single mistake, as opposed to simply using a language which entirely eliminates the class of flaw.