#
0c238ede |
| 07-Jul-2020 |
Tyson Andre |
[RFC] Only unserialize Phar metadata when getMetadata() is called In other words, don't automatically unserialize when the magic phar:// stream wrappers are used. RFC: https://wiki.p
[RFC] Only unserialize Phar metadata when getMetadata() is called In other words, don't automatically unserialize when the magic phar:// stream wrappers are used. RFC: https://wiki.php.net/rfc/phar_stop_autoloading_metadata Also, change the signature from `getMetadata()` to `getMetadata(array $unserialize_options = [])`. Start throwing earlier if setMetadata() is called and serialization threw. See https://externals.io/message/110856 and https://bugs.php.net/bug.php?id=76774 This was refactored to add a phar_metadata_tracker for the following reasons: - The way to properly copy a zval was previously implicit and undocumented (e.g. is it a pointer to a raw string or an actual value) - Avoid unnecessary serialization and unserialization in the most common case - If a metadata value is serialized once while saving a new/modified phar file, this allows reusing the same serialized string. - Have as few ways to copy/clone/lazily parse metadata (etc.) as possible, so that code changes can be limited to only a few places in the future. - Performance is hopefully not a concern - copying a string should be faster than unserializing a value, and metadata should be rare in most cases. Remove unnecessary skip in a test(Compression's unused) Add additional assertions about usage of persistent phars Improve robustness of `Phar*->setMetadata()` - Add sanity checks for edge cases freeing metadata, when destructors or serializers modify the phar recursively. - Typical use cases of php have phar.readonly=1 and would not be affected. Closes GH-5855
show more ...
|