@pablogsal, just curious: does adding this assert (and not the fix) make tons of tests crash on your build?

If so, my theory is that your compiler is optimizing out the old assert, since the failing case is always undefined behavior according to the C standard.

I will test this night or tomorrow, but I checked and I was indeed compiling in debug mode with asserts, so the old assert should have triggered. I'm curious to see what's going on so I will also investigate that, but that won't affect this issue or the PR, is just that I'm very curious to see what's going on there :)

Well, even if asserts were turned on, the inequality comparison between the pointers would be undefined if they're part of different allocations. Which is exactly the situation it was checking for!

So if the compiler could somehow prove that the comparison it was always true when the result was defined, it could have optimized it intoassert(1) or something.

But yeah, it doesn't affect this PR. The thing that's better about this new assert is that it's never undefined, and we don't need to overflow our stack chunk to trigger it. One failed call should do it (which is why so many tests crash if you add this without the fix).

So if the compiler could somehow prove that the comparison it was always true when the result was defined, it could have optimized it intoassert(1) or something.

I don't think so because I was compiling with -O0. If the compiler was being smart there I want my money back 🤣

Not that it matters much, but maybe you want to add the CPython specific decorator

I thought about that, but I figure that this should still pass on any CPython implementation. If you somehow crash here, it's a bug, right? 😉

Yeah, we have been approaching these kind of tests in different ways so it doesn't matter :)