On 1 August 2015 00:36:58 BST, Stanislav Malyshev <smalyshev@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
>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