Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118903
Message-ID: <039eefac-1554-6fd6-8c9d-5eb80efa21da@bastelstu.be>
Date: Fri, 28 Oct 2022 19:18:35 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Jeffrey Dafoe <JDafoe@fsx.com>, PHP internals <internals@lists.php.net>
References: <22177032-fe72-c39b-63fe-fa4368a70852@bastelstu.be>
 <beeb95cb-5f93-bbf2-50a4-1447589c5f68@bastelstu.be>
 <a692d77f06ee4d0eb8d19f58b41128f6@fsx.com>
In-Reply-To: <a692d77f06ee4d0eb8d19f58b41128f6@fsx.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [VOTE] Improve unserialize() error handling
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 10/28/22 18:25, Jeffrey Dafoe wrote:
> Informally, doesn't this mean that voters wanted a and c in PHP9?

Not necessarily. It might be that a voter does not like the Exception 
wrapping at all (thus declining the proposal), but *if* it happens to be 
accepted then also increasing everything to Exception would be be an 
obvious follow-up to them (thus declining the other proposal).

Also I've taken care to explicitly spell out the "terms of vote" before 
starting the voting to make sure voters are able to make an informed 
decision and making assumptions violates that informed decision.

> Does this vote mean it's dead for 9, or just that it needs a vote at some point in the future with the choices grouped different?
> 

I believe 
https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals answers 
your question here.

My understanding is that it may be reproposed after April 28, 2023, or 
earlier when substantial changes are made. Whether the change of target 
versions or voting dependencies constitute such a substantial change, I 
don't feel qualified to answer.

In any case I do not plan to repropose the RFC myself, for two reasons 
that both relate to the fact that I've written the RFC and developed the 
PoC patch in my free time (a co-worker proof-read the initial version of 
the RFC itself on company time, though):

a) The discussion phase and voting phase were both pretty exhausting to 
me mentally. One of the reasons is that the folks following the RFC on 
Twitter were not pointed to the related discussion thread, thus were 
missing out on important information and thus asked questions that were 
already answered without them knowing about it and needed to be answered 
again.

b) As a "personal time" contributor I personally find it demotivating if 
I need to wait until the next major (possibly multiple years) before I 
am able to use and rely on what I proposed myself.

I've written the RFC such that I am happy with what I proposed and such 
that I feel that I spent my free time well.

Even if the proposal was partly rejected, it ultimately still benefitted 
me, as I've learned something: I've learned that how I handled 
unserialize() failures in code I've written is unsafe and broken. I will 
improve my own code based on that and I strongly recommend everyone else 
who followed along the discussion to also do that:

The only safe error handling is (1) using a throwing error handler, and 
then (2) using catch(Throwable) without relying on a specific type of 
Exception.

------------

If someone wants to pick this up, they are free re-use (parts of) the 
words I've written for the RFC. The 'Increase the error reporting 
severity in the unserialize() parser' section will likely need to be 
rewritten, as the proposal (b) "unify Notice to Warning" passed. A short 
private heads-up is appreciated, but not required. If assistance with 
the C implementation is required, I might be able to help out as well.

Best regards
Tim Düsterhus