[Quekid5]

Imagine a comparison function that needs to call sort() as part of its implementation. You could argue that's probably a bad idea, but it would be a problem for this case.

(You could solve that with a manually maintained stack for the context in a thread local, but you'd have to do that case-by-case)

[groundzeros2015]

That is true. It can be protected against with assert.

I think the times you need to do this are few. And this version is much more pruden.

[Quekid5]

Assert what, exactly?

Anyway, the larger point is that a re-entrant general solution is desirable. The sort example might be a bit misguided, because who calls sort-inside-sort[0]? Nobody, realistically, but these types of issues are prevalent in the "how to do closures" area... and In C every API does it slightly differently, even if they're even aware of the issues.

[0] Because there's no community that likes nitpicking like the C (or C++) community. I considered preempting that objection :). C++ has solved this, so there's that.

[groundzeros2015]

> Assert what, exactly?

That you do not call it recursively by checking that the thread local is nil before invocation.

> a re-entrant general solution is desirable.

I know what you mean, but I just don't know why you want to emulate that in C. There is a real problem of people writing APIs that don't let you pass in data with your function pointer - the thread local method can solve 99% of those without changes to the original API.

But if you really want to do all kinds of first class functions with data, do you want to use C?