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

[Giuseppe D'Angelo]

Il 27/03/26 08:40, Marc Mutz via Development ha scritto:
> Hi again,
> 
> So you see how  we can't agree... ;)
> 
> Absence of proof is not proof of absence.

But a great number of data points makes for an educated estimate.


> We don't know what users do out there in the field. 

What is this referring to?

If it's referring to the countless ways through which people are storing 
their Connection objects, passing them around, using them etc., then 
it's all an argument for not touching these APIs at all, nor to tell 
users to touch them. The deprecation (or, even worse, moving to a 
move-only handle) will require annoying changes, all over the place. All 
of this because we don't want to put `mutable`, and because of a bug 
with zero impact?

Or if it's referring to the fact that users might be doing sanitized / 
LTO / who knows what kind of builds and possibly trampling into a 
manifestation of this UB? Because this claim isn't backed up by data. We 
know compilers aren't exploiting this UB.

And this doesn't mean we should clearly fix any gratuitous UB we find in 
Qt. We should and must. And in this case the complete fix is to add 
`mutable`. Emphasis on "gratuitous", because Qt is actually full of UB 
that we chose to actively exploit.


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

Sorry, but I reject this argument. *IF* we have a bug in inline code 
(and I disagree we have one), we fix the bug and tell users to upgrade, 
and that unfortunately they have to recompile to get the fix. This has 
nothing to do with the quality of this specific bug: any bug in inline 
code requires a recompilation.

Any other bug, requires an upgrade but not a recompilation.

But it's not realistic to expect a bug to be fixed without doing 
anything at all.


Also we don't send out emails unless the bug has a provable impact. All 
indications of this bug point to the fact that there's NO impact. Why 
are we being alarmist for this one specifically?


Finally, for those who can't upgrade and recompile, we might offer 
mitigation measures, but
1) we're in no way obligated to do so, and
2) could be as hacky as we like, including an unsupported patch that we 
don't intend to apply to trunk, ever.

If users can't upgrade their libraries, they'll have to live with bugs 
in those libraries, and it's not arrogant to state so.


> Finally, we do not know whether re-adding the "soft-leak" that 
> nulling the d_ptr plugs is going to hurt anyone out there.

There's no need to go there, `mutable` is the complete fix.

> 
> But all that are speculations. Users to this, compilers don't do that. 

It's not a speculation when it's backed by evidence: people have asked 
compilers to do the optimization we're afraid might be happening in 
inline code. Compiler authors acknowledged that it's a legit request, 
and that they're not doing this optimization right now.


> As such, that patch in itself is not the fix. It's a tool for users to 
> fix their code.

But then there's no need to be alarmist. We make the `mutable` fix and 
just publish a tiny PSA -- if you can't upgrade Qt, here's a workaround 
for you. And we don't require any other change by anyone else going 
forward, especially we don't deprecate such an API without good 
motivation for it?


My 2 c,

-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - Trusted Software Excellence
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4850 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260327/336e51e4/attachment.bin>