Possibly missing warning for `unserialize('')` - may be confused with "false"

[serious-angel]

Description

The following code:

<?php

error_reporting(E_ALL);
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');

$a = 'b:0;'; // serialize(false);
$b = '';

var_dump($a === $b);
var_dump(unserialize($a) === unserialize($b));

Resulted in this output:

bool(false)
bool(true)

But I expected this output instead:

bool(false)

Warning: unserialize(): Empty input in /in/bjBq9 on line 11
bool(true)

---

Dear Developers, Artists,

Thank you for the marvel, art...

On 2026-09-18, at Libera IRC channel #php, a member ash_worksi raised this issue asking why no warning is raised in PHP, if compared to unserialize(' ');, for example.

My contention is the fact that it doesn't raise a warning like the description says. It's a very narrow edge case, but just like any "non-unserializable" string (...otherwise why would it return false?) it should raise the warning.

unserialize() returning false on it's own does not tell you whether the function failed to unserialize or if the value you unserialized was in fact false.

~ ash_worksi

Later, I tried searching for the actual reason it happens, and the condition involved is likely the following, in the function php_unserialize_with_options:

php-src/ext/standard/var.c

Lines 1414 to 1416 in 13cec7c

	if (buf_len == 0) {
	RETURN_FALSE;
	}

The condition explicitly checks if the string is empty, and returns "false" by design, and considering the first commits checked, it has been so for at least "20 years ago".

I believe that for so much time, it was discussed already, but just in case, is it still actually expected?

Best and kind regards

PHP Version

PHP 8.5.10 (cli) (built: Sep 19 2026 00:23:53) (NTS)
Copyright (c) The PHP Group
Built by https://github.com/docker-library/php
Zend Engine v4.5.10, Copyright (c) Zend Technologies
    with Zend OPcache v8.5.10, Copyright (c), by Zend Technologies

Operating System

Kubuntu 26.10 (Docker)

[iliaal]

I am not sure raising a warning here is necessary, seems like BC implication. The false return already properly communicates a failure

[serious-angel]

The false return already properly communicates a failure

@iliaal , thank you for the response!

I am sorry, but just to clarify, how does the following communicate the error?:

var_dump(unserialize('b:0;'));
// bool(false)

var_dump(unserialize(''));
// bool(false)

[iliaal]

I don't think storing a boolean value in serialized data is all that common.

[ash-m]

You might find yourself hunting down a bug in the wrong location if a consumer yields false from unserialize() with the belief that the payload has been inadvertently modified on the consumer, rather than looking for a process that inadvertently yields false when the message is serialized on the producer.

[TimWolla]

The false return already properly communicates a failure

Quoting from the documentation:

In case the passed string is not unserializeable, false is returned and E_WARNING is issued.