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, and2) 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 | [email protected] | 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
smime.p7s
Description: Firma crittografica S/MIME
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
