You can copy the pointers, but that doesn't make it safe because you could have pointers to stack values.

I don't see how that's relevant. If a developer sets a pointer to point to a stack object then copying the pointer, whether manually or through a hypothetical closure, doesn't change nor create the problem.

The problem is returning a closure that points to a stack variable that's now out of scope.

It isn't. The hypothetical problem was setting a pointer to a stack variable. That's a no-no from the start, and adding hypothetical closures to the mix changes nothing.

Having a pointer to a stack variable is fine, as long as the stack variable lives longer than the closure.

Right, so your original claim about properly cleaning up is not the only problem with closures in C. There are quite a few hazards actually.

> Right, so your original claim about properly cleaning up is not the only problem with closures in C.

Your comment makes no sense. OP stated that your hypothetical problem isn't even a problem if the developer knows what he is doing, and your take from that is that there are more problems?

The original poster said the trouble was cleaning up after the closure is no longer needed. That's clearly not the case as this thread has covered. I thought the previous poster was the original poster, so just replace "your original claim" with "the original claim".