On 18/10/22 22:32, Tim Düsterhus wrote:
false is a valid value that might've been serialized. The manual
specifically notes:
false is returned both in the case of an error and if
unserializing the serialized false value. It is possible to catch
this special case by comparing data with
On Tue, Oct 18, 2022, at 12:22 PM, Tim Düsterhus wrote:
>>> Generating a random string containing specific characters...thus requires
>>> multiple lines of code for what effectively is a very simple operation.
>>
>> Yeah, though those lines of code add distinction and emphasis for is
>> meant
On Tue, Oct 18, 2022 at 10:22 AM Tim Düsterhus wrote:
>
> This cannot be reasonably done in userland, because you pay an increased
> cost to turn the bytes into numbers and then to perform the necessary
> bit fiddling to debias the numbers.
>
To add to this, I'm going to link to a userland
> > The other failing tests involve "unserialize_callback_func" to gracefully
> > detect class-not-found, and they are all plain broken by the RFC.
> >
> > I created this patch/PR to show the changes that would be required on
> > Symfony to work around the BC break:
> >
Hi
On 10/16/22 22:24, Dan Ackroyd wrote:
Shall an option be added to getFloat() that changes the logic to
select from [$min, $max] (i.e. allowing the maximum to be returned)? And
how should that look like? Boolean parameter? Enum?
An enum would probably be nice, and possibly be for all four
Hi Tim,
On Fri, 14 Oct 2022 at 15:44, Tim Düsterhus wrote:
>
> Hi
>
> as announced on Wednesday [1] I've now opened the vote for:
>
> "Improve unserialize() error handling" [2]
I'm going to have to vote no for changing to throwing an exception.
The BC break is too big imo, and too hard for
Hi
On 10/18/22 03:26, Tim Starling wrote:
If I'm reading the implementation correctly, the original exception is
thrown away, there's no way to get the original message and backtrace.
That will make debugging more difficult.
See Derick's reply (and my reply to Derick's reply).
I reviewed
Hi
On 10/18/22 09:32, Derick Rethans wrote:
If I'm reading the implementation correctly, the original exception
is thrown away, there's no way to get the
original message and backtrace.
That will make debugging more difficult.
I believe that is not true. It should be wrapped and accessible
On 18 October 2022 02:26:59 BST, Tim Starling wrote:
> If I'm reading the implementation correctly, the original exception
> is thrown away, there's no way to get the
> original message and backtrace.
> That will make debugging more difficult.
I believe that is not true. It should be wrapped
