[Development] QArrayDataOps/Pointer UB post-mortem

[Thiago Macieira]

On Tuesday, 26 May 2026 00:51:35 Pacific Daylight Time Marc Mutz via 
Development wrote:
>  It means it didn't blow up at some customer first (for all we know)

For all we know, it did. We did not root-cause to which version of GCC applies 
the optimisation, so we don't know how long the latent bug has been there. I 
could reproduce the issue with three different versions (14, 15 and 16) and GCC 
14 is from 2024, so the issue has been reproducible for at lest two years. I 
did *not* test with 13 or earlier versions.

That said, we have *not* observed it in QList, QByteArray and QString. It 
showed up in SimpleVector, and it might have shown up there *only* because 
it's simple. Therefore, even though the bug has been latent since Qt 5.0, for 
all we know it has never expressed itself and never would have.

> Several highly-esteemed developers and two chat bots concluded that this is
> a compiler bug.

BTW, my prompt to Claude was:

 I have a test bug that looks like a compiler problem. It could be a source 
problem, but I don't think so.
 When running @tests/auto/corelib/tools/qarraydata/tst_qarraydata.cpp test 
arrayDataOps, I get the following output:
...
 The compiled assembly is @tst_qarraydata.cpp.s and the object file is 
@tst_qarraydata.cpp.o

So I did tell it that the problem could be a compiler bug. That's probably 
confirmation bias, because I had concluded the same.

But in any case, it found the exact same piece of assembly I had and concluded 
the exact same thing: the cached size wasn't updated.

What we both got wrong is the attribution: the issue wasn't a compiler bug, 
but a source code bug that caused UB.

> To me, this issue reinforces what I have known to be true for years, to wit:
> - the compiler is more clever than you, you MUST NOT fall into UB,
> regardless of whether _you_ think it's benign (even if you think you can
> prove it) 
> - only features shouldn't be picked back, in particular
>   - test changes should always be picked back, with a XFAIL, if necessary
>   - refactorings should always be picked back (or not done at all)
>   - bugfixes should always be picked back

Agreed in principle, but in practice it's hard. First, some bugfixes are 
themselves risky or change behaviour, so applying the fix may not be a good 
idea. That's a subjective question.

Second, very often a bugfix happens after a feature has changed the code, which 
wasn't picked packwards. Picking the bugfix is not trivial either, due to 
unavoidable conflicts, as you've seen. That's natural, though.

-- 
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: 5176 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260526/0e5d2657/attachment.bin>