-
Notifications
You must be signed in to change notification settings - Fork 8k
Fix GH-14402: Add support for serialization in SplPriorityQueue, SplMinHeap and SplMaxHeap #19447
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix GH-14402: Add support for serialization in SplPriorityQueue, SplMinHeap and SplMaxHeap #19447
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the serialization format is unsafe when facing inheritance, since it doesn't clearly distinguish between “regular properties” and “internal state”. Please have a look at the serialization implementation of ext/random engines for a robust example and make sure to include proper error handling (i.e. throwing an \Exception
) when the data does not look as expected during unserialization. Silently doing nothing when the zval types do not match is not okay.
501e55d
to
bec66ee
Compare
I pushed a new version with 3 additional tests:
Tests I pushed are pretty verbose and human friendly, I wonder if they should look like |
I addressed all your comments in 3f041a3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we prevent serialization if the SPL_HEAP_CORRUPTED
flag is set?
I'm also noticing that this PR targets PHP 8.3. I'd argue this is more a feature rather than a bugfix and would recommend targeting master.
Maintenance-wise I think “technical tests” are preferable, this makes sure that they capture every nuance and with the diff output any failures are still pretty readable. You could also take a look at the serialization tests for ext/random. Given that it's a very new extension, I'd say it's in a good shape. And I made sure to very carefully maintain the tests there. |
Yes. I targeted 8.3 because of the bug label on the issue, but it definitely looks like a feature. Let's target master. |
3f041a3
to
5209c63
Compare
5209c63
to
2236ca2
Compare
4478ef7
to
bb54148
Compare
The two last commits rearrange tests with a more technical approach, adds some more tests and safety about the heap being corrupted. Also, more code form |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic now looks robust to me (didn't look at the test). But as I'm not familiar with the code, I would like to see someone else do a review.
bb54148
to
04bb7cd
Compare
Thanks for the extensive review @TimWolla! |
I don't really know how SplHeap works, maybe @arnaud-lb or @iluuu1994 can review this instead? |
Looking at the code, this doesn't seem to be necessary. The flag is only added when order is not guaranteed anymore. From an engine/memory perspective, the heap is still consistent. The heap remains readable, and the flag can be reset by userland ( |
5091647
to
82eea74
Compare
Thanks Arnaud! Comments addressed |
Actually, trying to unserialize a corrupted heap would likely throw, and fail, so it's not useful to allow serialization of a corrupted heap. The PR currently prevents it, too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me!
I don't think it qualifies as a bugfix, so merging in master right now would require @php/release-managers-85 approval.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RM approval, technical review not performed
82eea74
to
2488e8e
Compare
…plMinHeap and SplMaxHeap
2488e8e
to
63a7546
Compare
Fix #14402