Am Montag, dem 04.12.2023 um 15:35 -0500 schrieb Siddhesh Poyarekar: > 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.
The proposal we have seen for C23 (which was not accepted into C23 mostly due to timing and lack of implementation experience) were similar to C++'s lambdas and did not have any such restriction. > > 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. Updating some variable is useful for example for contractions, e.g. summing over a certain range of values in an array, etc. > > > > 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. I submitted a patch for this a long time ago which was based on the code for Ada that uses a bit in the pointer to differentiate between conventional pointers and descriptors. I would now prefer an approach that uses a qualifier on the function type to indicate that the static chain has to be set. A pointer to such a qualified function would a descriptor that consists of the address and the value for the static chain. This would be useful for many things. Martin
