On 1 August 2015 00:36:58 BST, Stanislav Malyshev <smalys...@gmail.com> wrote: >Hi! > >> As I have pointed out several times, it is only the 'args' section of >> the backtrace that ever contains unserializable items. The solution > >previous could too. In fact, right now, since you can unserialize >exceptions, previous can contain literally anything and so can any >other >members. Also, user code can modify any protected properties too.
By that logic, *no* object should be Serializable, because attempting to do so might recurse to a property that can't be. That doesn't make any sense; what we're talking about here are the native properties of a standard exception, not random data stuffed into the data by a user. >> DEBUG_BACKTRACE_IGNORE_ARGS in a debug_backtrace() call. IIRC the >> object of called methods is already excluded (equivalent to masking >> out DEBUG_PROVIDE_OBJECT) so what's left is all strings. > >I'm not sure how you arrived at the conclusion that all arguments in >backtrace are strings. Arguments can be of any type. When printed, they >are converted to strings, but they are not strings when stored. I'll have to recheck when I have more time, and something better than a phone to type on, but from memory, the backtrace which can be retrieved from an exception includes the same information as debug_backtrace(false), that is: - function: string - line: integer - file: string - class: string - type: string - args: array Of these 6 items, it is only 'args' that can contain an object of any kind, so without this item, the data would be serializable. This would be equivalent to debug_backtrace( DEBUG_BACKTRACE_IGNORE_ARGS). If any of these items (other than args) are stored in memory in a different form (which doesn't seem likely to me), that form is completely inaccessible to the user, so converting to string during serialization would effectively be lossless. (Or, pre-converting would have zero BC break.) Similarly, if additional details are stored, those details are inaccessible, so removing them has no impact on any existing (userland) code. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
