On 2023-12-04 13:48, Martin Uecker wrote:
I empathize with Jakub's stated use case though of keeping the C
frontend support for testing purposes, but that could easily be done
behind a flag, or by putting nested C func deprecation behind a flag.
I am relatively sure C will get some form of nested functions.
Maybe as anonymous nested functions, i.e. lambdas, but I do
not see a fundamental difference here (I personally like naming
things for clarity, so i prefer named nested functions)
If (assuming from them being called lambdas) they are primarily for
small functions without side-effects then it's already a significantly
stronger specification than what we have right now with C nested
functions. That would end up enforcing what you demonstrate as the good
way to use nested functions.
I suppose minimal, contained side-effects (such as atomically updating a
structure) may also constitute sound design, but that should be made
explicit in the language.
I don't disagree for cases like -Warray-bounds,
but for warnings/errors that are more deterministic in nature (like
-Werror=trampolines), they're going to point at actual problems and
larger projects and distributions will usually prefer to at least track
them, if not actually fix them. For Fedora we tend to provide macro
overrides for packages that need to explicitly disable a security
related flag.
In projects such as mine, this will lead to a lot of code
transformations as indicated above, i.e. much worse code.
One could get away with it, since nested functions are rarely
used, but I think this is bad, because a lot of code would
improve if it used them.
If nested functions are eventually going to make it into the C standard
then effort is probably better spent in porting the C nested functions
to use descriptors instead of executable stacks or heaps.
Thanks,
Sid
