On Monday 29 July 2024 10:49:20 GMT-7 Frederick Virchanza Gotham via Std-
Proposals wrote:
> Although in most cases, once you call the original function in the
> library, any subsequent recursive calls will directly call the original
> function, thus bypassing the interceptor

That's an unproven assumption. It's the use-case you came up with: needing to
lock a mutex, which presumably won't be a recursive one. But by that you
ignore many other use-cases, for example those that want to inspect the
returned value and modify it.

Using a pre-allocated maximum recursion buffer is one way to do it... but
fragile. It's easy to mis-estimate how many recursions would be necessary:
suppose for example that the feature is in use in other portions of the code,
so they'd all be using the same shadow stack for this thread. I suppose on a
large operating system, you'd simply allocate this shadow stack to the same
size as the thread's main stack and, like it, not commit memory until it's
needed. But C++ needs to explain this for constrained systems too, which would
imply doubling of the stack space for a seldom-used feature.

And like I said in the other email: you can't explain how to install the
interceptor using the Standard. This feature does not belong in there.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering