I can propose a solution that maintains consistent syntax across runtime, link-time, and compile-time. The only difference lies in how the functions are renamed and redirected.


For link-time:
[[hook __wrap]]
int send(fd, buf, len, flags);
This behaves similarly to g++ --wrap. Here, __real_send refers to the send function in the static library, while __wrap_send is the specialized version generated from __wrap(send). During linking, calls to send are redirected to __wrap(__real_send).


For runtime:
[[hook __wrap]] int send(fd, buf, len, flags);
This is equivalent to:

auto __real__send = FindFunctionInLibrary("send");
auto send = __wrap(__real_send);
Here, __wrap(__real_send) is instantiated first. Then, when the program loads the dynamic library at startup, it locates the send function within that library and assigns it to __real_send. Note that this mechanism is restricted to the dynamic library loading phase.


For compile-time:
[[hook __wrap]]
int real_send(int fd, const void *buf, size_t len, int flags);
In this case, real_send is renamed to real_send_#__line__ (to prevent naming conflicts).
Then, the logic becomes:
auto real_send = __wrap(real_send_#__line__);




At 2026-04-18 01:02:11, "Thiago Macieira" <thiago_at_[hidden]> wrote:
>On Friday, 17 April 2026 03:43:00 Pacific Daylight Time Zhao YunShan wrote:
>> > - it is a static facility, many would prefer runtime configuration
>>
>> That's another subjective assertion. Being able to implement both static and
>> runtime features is progress. Use whichever you prefer.
>
>This was direct feedback consequence of how you described the feature syntax:
>there was no way to intercept at runtime, if the compiler didn't see the
>declaration.
>
>This is why you must write the paper. It's not clear how it's going to work.
>You may have thought of things that you didn't express well in the email and
>thus the rest of us are only seeing a limited subset of the capability.
>
>> Reflection is less efficient than Interceptors. By the way, we are
>> discussing Interceptors, so why did you bring up Reflection? It feels like
>> you're not really familiar with either of them.
>
>Why are they less efficient? Reflection happens entirely at compile time, so it's
>as efficient as any compiled code can be, including inlining. Interception can't
>catch inlined calls, because they have been inlined.
>
>The reason Sebastian brought this up is that one typical case of
>"interception" is to create mock classes for testing, so one can verify that
>the right functions are called, the expected arguments are passed,
>preconditions and postcondition are met, etc. Having the ability to reflect an
>existing class and automatically create a mock would be extremely useful.
>
>And yet this is not always possible to do, if one can't replace the class that
>is being called, buried deep inside layers of code. Intercepting the class at
>runtime would be useful.

>--
>Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.