Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118568
MIME-Version: 1.0
References: <530b3a9d-0ee4-6061-8c69-df672d238032@bastelstu.be>
In-Reply-To: <530b3a9d-0ee4-6061-8c69-df672d238032@bastelstu.be>
Date: Tue, 6 Sep 2022 12:14:13 +0100
Message-ID: <CAFPFaMJ0V8vZC2inepmZcTQeR0b0+NXgBFSFosPM90kWY3KUDQ@mail.gmail.com>
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000079c52a05e8004ca7"
Subject: Re: [PHP-DEV] RFC [Discussion]: Improve unserialize() error handling
From: george.banyard@gmail.com ("G. P. B.")

--00000000000079c52a05e8004ca7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 5 Sept 2022 at 18:20, Tim D=C3=BCsterhus <tim@bastelstu.be> wrote:

> Hi
>
> I've now written up an RFC as a follow-up for the "What type of
> Exception to use for unserialize() failure?" thread [1]:
>
> ----
>
> RFC: Improve unserialize() error handling
> https://wiki.php.net/rfc/improve_unserialize_error_handling
>
> Proof of concept implementation is in:
>
> https://github.com/php/php-src/pull/9425
>
> Discussion period for that RFC is officially opened up.
>
> ----
>
> The primary point of discussion in the previous mailing list thread and
> in the PR comments is whether unserialize() should continue to emit
> E_WARNING or whether that should consistently be changed to an
> Exception. As of now I plan to explicitly vote on this and the RFC
> contains some opinions on that matter.
>
> Best regards
> Tim D=C3=BCsterhus
>
> [1] https://externals.io/message/118311
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Thank you Tim for the thorough investigation.
I didn't know how bad the situation was in regards to unserialization.
So I'm now tending in favour of promoting the notice/warnings to exceptions
as it is currently extremely hard to handle the behaviour correctly.

Best regards,

George P. Banyard

--00000000000079c52a05e8004ca7--