I’ve apparently not checked 32-bit, though 🤦‍♂️

One option is to remove this test entirely. We already had to tweak it with @NickBarnes, so it's consumed some amount of maintenance time already, and hasn't caught any regression that I know of. We could forget about it. My worry is that its unreliability might be hiding other issues (maybe on 32bit settings?) that we should know about, and we would forget about conveniently if we just drop the test.

So this test originally came from @TheLortex in #12062 - it was added because at the time the consumer would note that an event was dropped but still go ahead and try to parse it anyway, which resulted in a segfault sometimes (and incorrect data).

I think the new robustness is a good idea.

My worry about dropping this test is the same as @gasche though, is it hiding issues on lesser-used platforms where we've just not had any reports? I think given the way the test is written on trunk, a failure is generally a bad sign.

This test appears to be broken in trunk (I see it fail semi-regularly on clang-cl at least). In #13476 I propose to disable it on Windows for now.

Temporarily pushed with msvc restored, but this should not be merged with #13476 reverted.

I tested this locally (on Linux and Windows) with the fix in #12062 reverted, and it's very quickly and consistently catching it (as a corrupt ring, rather than a segfault).