On Sun, Apr 19, 2026 at 5:08 AM Thiago Macieira wrote:
>
> > My own thread = Interceptor Functions [runtime]
> > Zhao's thread = Interceptor Functions [compile-time]
>
> No.
>
> First, threads are threads. Most people don't change the subject. So if you
> start a thread with a subject, it will stay. So you and YunShan decide the
> subject.
>
> Second, the two features are too similar to be accepted separately in the
> standard, or even be discussed. Either of them being proposed would trigger a
> discussion about the other side. Therefore, no matter what separation you may
> have, the efforts will bleed into one another.


I totally disagree with you. I see mine and Zhao's proposed features
as very different.

For my own feature, let's say we have a proprietary compiled shared
library, something like "libgraphics.so". And let's say we also have a
proprietary compiled executable called "graphics.bin". The latter
depends on the former.

So I come along as either a debugger, a logger, or reverse-engineer,
and I decide to create a "man in the middle". So I use "nm" to list
all the exported functions from the library, and I see a few unmangled
names:

OpenArchive
CloseArchive
InsertItemIntoArchive
RemoveItemFromArchive

I've no idea what the signature is for any of these four functions --
I don't know the return type and I don't know how many parameters they
take. Therefore if I write an interceptor function, I must make sure
that all argument registers are preserved and that nothing gets pushed
onto nor popped off the stack. The is why an interceptor function has
no return type and no parameters:

[[interceptor]] void Func(void)
{
    goto -> some_global_variable;
}

So I could make a man in the middle library that exports four
functions: OpenArchive, CloseArchive, InsertItemIntoArchive,
RemoveItemFromArchive, and each of these exported function is an
interceptor that does logging and then jumps to the real function in
the original shared library.

Note that my interceptor functions require no knowledge whatsoever of
the target function, and that all known ABI's and calling conventions
are supported (e.g. 32-Bit: stdcall, cdecl, thiscall. 64-Bit: System
V, msabi). My interceptor functions allow communication between
binaries built from different programming languages, as you don't need
to know what size or alignment anything is (so long as a calling
convention is abided).

YunShan is doing something very different -- YunShan knows the
everything he needs to know about the intercepted function: its return
type, its parameters, its calling convention, and he's getting the
compiler to do the interception at compile-time. YunShan is only
concerned with forwarding function arguments and preserving the return
value, which is a layer above the more basic operations of preserving
CPU registers and the stack.

I see these two features as very different and not particularly related.