[Development] HEADS UP: do not pass const objects to QObject::disconnect(const QMetaObject::Connection&)!

[Thiago Macieira]

On Friday, 27 March 2026 03:40:43 Eastern Daylight Time Marc Mutz via 
Development wrote:
> We don't know what users do out there in the field. All we know is a) the
> behaviour of the function as of now and b) that if you pass objects
> originally marked as const, that's UB, according to the standard.

No, we know more. We have 14 years of evidence of what compilers *actually* 
generate for this code. We have constraint boundaries based on what the 
compiler can see from the code. Yes it's UB, but the compiler is not 
clairvoyant and omniscient: it's a deterministic machine that produces outputs 
based on observable inputs.

See my email reply to Peppe on what I think is the only possible outcome of 
the UB. Anything else would require LTO, which then only affects QtCore (I 
don't care about static builds).

> We specifically do not know, whether passing const objects actually does
> "something", we also do not know whether users can upgrade their Qt to
> receive any of the two other proposed fixes (mutable or not nulling d_ptr).

We do know: they can at least patch. This is no different than any bug they may 
be affected by and wish to see solved. It's unreasonable to expect bugs to 
disappear when no changes are applied anywhere.

> Finally, we do not know whether re-adding the "soft-leak" that nulling the
> d_ptr plugs is going to hurt anyone out there. We can speculate, e.g.,
> that, since disconnect() already cleaned up, users may just free() a buffer
> of Connection objects instead of running their destructors, turning a
> "soft" into a "hard" leak.

That's their own bug. Buggy code is buggy and we need not consider whether we 
end up making it worse by fixing our own.

> But all that are speculations. Users to this, compilers don't do that. After
> 14 years in the wild, at the intersection of Hyrum's and Murphy's Laws,
> everything we can think of happening probably does happen out there. I also
> wouldn't've imagined to see a QHash<const char*> ever in my life. I found
> several just the other week. We also thought file-static functions do not
> have an effect outside their TU. And then came Unity Builds (and it's not
> that we couldn't know - KDE has had that feature since automake times,
> IIRC).

Unity builds should not be considered for the purposes of performance or 
quality. They are a hack and I ignore they exist. If I break them, it's SEP.

ONLY LTO matters: that's the state of the art.

> I am not saying we shouldn't add the mutable. In fact, I have a patch up,
> and think it's a viable mitigation strategy. But it's just another
> assumption: that users can upgrade their Qt. I would say that the only safe
> assumption to make is that _if_ users can update _anything_ in their
> product, that their own code is always one of these things.

I say we fix this, but we treat it as a regular ol' bug.

We have UB all the time: any null or dangling pointer dereference is UB. Those 
*have* been observed in the wild. And yet we don't create such a fuss about 
them.

> Though, come to think of it, even users that cannot update anything, can at
> least apply the mutable patch, recompile, and see whether their product is
> byte-for-byte identical. If it is, then there's nothing to do, either. If
> there are differences, return to the start. Assumes reproducible builds, of
> course.

That is the least invasive patch, indeed. But I don't know we need to go to 
those extreme efforts for "regular ol' bug".

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCG - Platform & Sys. Eng.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5150 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260327/8c4bdd60/attachment.bin>