@smalyshev Does this look reasonable?

I like the idea of having it but I am concerned about the surprise effect of breaking somebody's data (and yes, 4096 is a lot, but I've seen lots of weird data, who knows...). How about doing it this way:

• having ini value - something like unserialize.max_depth - with the default of 4096, documented in php.ini and UPGRADING
• making this function default to the value of that ini value

This improves several things:

• Spotting new ini value is easier than spotting new optional value inside optional parameter and figuring out how to change it
• If it breaks anything for you, it's easy to get back to previous state without changing any code
• It's easier to make it much tighter if needed without changing every unserialize call

Generally we're pretty cautious with new ini values, but this looks like a kind of thing that would work well with one.

I've now added an unserialize.max_depth ini option to specify the default depth limit and also changed the behavior of max_depth wrt nested unserialize. If an inner unserialize sets max_depth, then we'll reset the depth to zero as well. When switching back to the outer unserialize the depth/max_depth is restored.

Any thoughts on the naming of the ini setting? I've called it unserialize.max_depth, but we have an existing unserialize_callback_func, so maybe it makes more sense to use unserialize_max_depth (without the dot)?

For consistency I prefer without the dot

Yeah, without the dot for consistency would be my opinion too.

I've renamed the ini setting and merged this as 1806ce9 into 7.4.

This change isn't documented in UPGRADING what I can tell.

@tored 1806ce9#diff-7748eb3bfdd3bf962553f6f9f2723c45

My apologies, was looking in the master branch and not the php-7.4 branch.