C++ Logo

std-proposals

Advanced search

Re: [std-proposals] interceptor functions (tested and working on x86_64)

From: Jonathan Wakely <cxx_at_[hidden]>
Date: Fri, 1 May 2026 12:40:48 +0100
On Fri, 1 May 2026 at 09:39, David Brown via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On 01/05/2026 09:39, Frederick Virchanza Gotham via Std-Proposals wrote:
> > In response to David, Jonathan and Thiago chronologically:
> >
> >
> >
> > Thiago:
> > > What could possibly be the use-case for intercepting printf? How do
> > you even
> > > know what the mangling of "printf" is (hint: it's not `printf`
> > everywhere)?
> >
> >
> >
> > Not sure why you're making this point, because the address of 'printf'
> > gets resolved in C++, not in assembler, and so the compiler handles the
> > mangling. We don't need to know the mangled name of printf.
> >
>
> That's not true, AFAIUI. Function addresses are resolved by the linker
> - not the compiler.
>

I think he didn't mean "address", he meant that overload resolution in the
compiler decides which symbol "std::printf" resolves to for a given
expression. The actual *address* of that symbol is decided much later, but
turning a call to printf into a reference to some symbol name (mangled or
not) happens in the compiler.



>
> And for standard functions where the compiler knows exactly what the
> function does, or other functions when the compiler can see the source,
> the compiler is not in any way obliged to generate direct calls to the
> function. gcc will, for example, generate code for
>
> printf("Hello, world!\n");
>
> with a call to "puts".
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

Received on 2026-05-01 11:41:07