Invalid utf8 causing partially missing output

[radiat-r]

phpunit/src/Util/Printer.php provides a function write, which has this line:
$buffer = htmlspecialchars($buffer);

The use of htmlspecialchars in combination with invalid utf8 is problematic:
PHP: htmlspecialchars

If the input string contains an invalid code unit sequence within the given encoding an empty string will be returned, unless either the ENT_IGNORE or ENT_SUBSTITUTE flags are set.

This can lead to irritating behaviour, when Printer->write is fed with such input.

Take for example the following simple test:

<?php

class Invalid_UTF8_Test extends PHPUnit_Framework_TestCase
{
    public function test_invalid_utf8()
    {
        $this->assertSame("\xbf", '');
    }
}

the output of phpunit will look like this:

PHPUnit 5.2.4 by Sebastian Bergmann and contributors.

Runtime:       PHP 5.6.22 with Xdebug 2.4.0
Configuration: XXX/phpunit.xml

F                                                                   1 / 1 (100%)

Time: 167 ms, Memory: 7.50MB

There was 1 failure:

1) Invalid_UTF8_Test::test_invalid_utf8

FAILURES!
Tests: 1, Assertions: 1, Failures: 1.

It will print, that a failure occured, but not where exactly and what went wrong.

It get´s even worse, when you use a dataProvider:

<?php

class Invalid_UTF8_Test extends PHPUnit_Framework_TestCase
{
    public function provider_invalid_utf8()
    {
        return [
            ["\xbf"],
        ];
    }

    /**
     * @dataProvider provider_invalid_utf8
     */
    public function test_invalid_utf8($input)
    {
        $this->assertSame($input, '');
    }
}

Now the output will look like this:

PHPUnit 5.2.4 by Sebastian Bergmann and contributors.

Runtime:       PHP 5.6.22 with Xdebug 2.4.0
Configuration: XXX/phpunit.xml

F                                                                   1 / 1 (100%)

Time: 148 ms, Memory: 7.75MB

There was 1 failure:

FAILURES!
Tests: 1, Assertions: 1, Failures: 1.

Now you can´t even see in which test the failure occured.

The issue is solved, when the above line in Printer->write is changed to:
$buffer = htmlspecialchars($buffer, ENT_SUBSTITUTE);

While this may look like a constructed example, i actually hit this problem when writing tests to check how our code is handling invalid utf8.

[sgabler]

Looks like this could be turned into a one-line pull-request, @radiat-r? Or does changing it to $buffer = htmlspecialchars($buffer, ENT_SUBSTITUTE); give anyone cause for concern?