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@macieira.org> 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.