On Sunday, 19 April 2026 04:46:44 Pacific Daylight Time Frederick Virchanza
Gotham via Std-Proposals wrote:
> I totally disagree with you. I see mine and Zhao's proposed features
> as very different.

They are different, but still doing something similar that will trigger
discussion.

> 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:

I'm pretty sure the discussion in the committee would go something like:
"This is all sorts of violations. We don't want it in the Standard"
"Yeah, agreed. But if the function declared it could be intercepted, would
that be ok?"
"I suppose. That would allow the compiler to write the interceptions at
compile time too, right?"
"Interesting, that could help unit-testing and mocking."

> 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.

I'm pretty sure this motivation is DOA.

> 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.

The problem is that his bleeds into yours. His has to include the ability of
runtime interception too. The fact that it matches the function signature is
indeed different from your proposal is not taken into account in your thread
subject separation. You should add "opaque" in your proposal.

His has a chance of being accepted. Yours I don't think does.

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