On Sunday, 27 April 2025 01:50:50 Pacific Daylight Time Tiago Freire via Std-
Discussion wrote:
> If 2 functions produce the exact same byte code, does it matter which one
> you call?

The problem is not the one you call. The problem is when you take their
addresses. Empty functions or empty objects could be used as identity tag
markers and therefore should *not* be merged, if their address is taken.

> I would even go one step further, after the code is compiled, and if you
> know the addresses of those functions and all the locations where they are
> called from, and if you replaced all the references of foo with bar and
> completely erased foo, would it even produce any visible side effects?

They could, if they are stored and compared for equality.

> Now it is possible. I acknowledge that, one can do some function pointer
> shenanigans, where you would take the address of a function and use it to
> track state in a way that doesn't necessarily involve calling the function
> itself. But in my entire career, the amount of times I have seen that
> pattern is exactly 0. And I question the validity of such a pattern given
> that you are also willing to accept that the same function could yield
> different addresses depending of context.

That's exactly the pattern that Qt signals use since Qt 5.0. The pointer to
the signal member function is used as an identifier for *which* signal was
emitted. Now, moc will not emit the same code for two different signals —
either the meta object pointer will be different or the local ID will be — but
the principle of the thing still is that we expect function pointers to be
unique when pointing to different functions.

This also shows how they *must* be merged if they indeed are the same
function. That's something I've had to fight with architectures and build flags,
and is non-standard.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering