The maximum zlog message length is 1024 including timestamp et cetera.

With very long messages over 1024 characters, these get wrapped into multiple chunks correctly, but then the "WARNING: child blah said into blah" gets added and the zlog call truncates the messages using "..." at the end, resulting in a couple dozen bytes getting lost.

This change calculates the length at which wrapping needs to occur correctly.

To reproduce, log a long message to stderr, e.g. a bit of Shakespeare:

file_put_contents('php://stderr', "If it were done when 'tis done, then 'twere well // It were done quickly. If the assassination // Could trammel up the consequence, and catch, // With his surcease, success; that but this blow // Might be the be-all and the end-all--here, // But here, upon this bank and shoal of time,-- // We'd jump the life to come. But in these cases // We still have judgement here; that we but teach // Bloody instructions, which being taught, return // To plague the inventor: this even-handed justice // Commends the ingredients of our poison'd chalice // To our own lips. He's here in double trust: // First, as I am his kinsman and his subject, // Strong both against the deed: then, as his host, // Who should against his murderer shut the door, // Not bear the knife myself. Besides, this Duncan // Hath borne his faculties so meek, hath been // So clear in his great office, that his virtues // Will plead like angels, trumpet-tongued, against // The deep damnation of his taking-off: // And pity, like a naked new-born babe, // Striding the blast, or heaven's cherubin, hors'd // Upon the sightless couriers of the air, // Shall blow the horrid deed in every eye, // That tears shall drown the wind.--I have no spur // To prick the sides of my intent, but only // Vaulting ambition, which o'erleaps itself, // And falls on the other. // Is this a dagger which I see before me, // The handle toward my hand? Come, let me clutch thee:-- // I have thee not, and yet I see thee still. // Art thou not, fatal vision, sensible // To feeling as to sight? or art thou but // A dagger of the mind, a false creation, // Proceeding from the heat-oppressed brain? // I see thee yet, in form as palpable // As this which now I draw. // Thou marshall'st me the way that I was going; // And such an instrument I was to use. // Mine eyes are made the fools o' the other senses, // Or else worth all the rest: I see thee still; // And on thy blade and dudgeon gouts of blood, // Which was not so before.--There's no such thing: // It is the bloody business which informs // Thus to mine eyes.--Now o'er the one half-world // Nature seems dead, and wicked dreams abuse // The curtain'd sleep; now witchcraft celebrates // Pale Hecate's offerings; and wither'd murder, // Alarum'd by his sentinel, the wolf, // Whose howl's his watch, thus with his stealthy pace, // With Tarquin's ravishing strides, towards his design // Moves like a ghost.--Thou sure and firm-set earth, // Hear not my steps, which way they walk, for fear // Thy very stones prate of my whereabout, // And take the present horror from the time, // Which now suits with it.--Whiles I threat, he lives; // Words to the heat of deeds too cold breath gives. // ");

This bugfix attempts to resolve 37676. It will make sure that the container is either compiled, or if it's a return-variable make sure it's something that we know is error-able.

Updated tests to account for the E_NOTICE that will go out with this fix.

Other related bugs: 39915 72636

This is a followup of https://bugs.php.net/bug.php?id=72768

TL;DR Console apps of newer Windows 10 versions support colors, but we need to manually set the ENABLE_VIRTUAL_TERMINAL_PROCESSING console flag.

Here's my proposal of a new userland function: bool stream_vt100_support(resource stream[, bool enable])

Where:

• stream should be STDOUT orSTDERR
• if enable missing: the function returns true if the specified stream supports colors
• if enable is true: the function tries to enable color support for the stream (return true on success)
• if enable is false: the function tries to disable color support for the stream (return true on success)

To be done:

• [X] currently the function accepts a string (eg php://stdout): it should instead accept a stream resource
• [X] tests

On startup, PHP may execute a script defined by opcache.preload configuration directive. All function and classes loaded by this script became permanent and available to all the following requests. For example, it's possible to preload almost whole Zend Framework, and save significant time on each request.

This is an unfinished PoC yet.

This is a proof of concept for built-in mixed type for parameter types and return types. The behavior of mixed type matches the behavior when no type is specified (thus being implicitly mixed). Primary motivation for having explicit mixed type is consistence and easier static analysis. In PHP 7.2, mixed types are unfortunately the only type that could not be type hinted upon (true, resource as well, but its future is unclear). I believe having mixed type would polish the code interface even more, thus having code with 100% explicit type hint coverage.

Before:

<?php
function foo($arg) {
    return $arg;
}

Now:

<?php
function foo(mixed $arg): mixed {
    return $arg;
}

(Note that I barely know the PHP internals so this may be entirely wrong approach.)

TODOs:

• [x] disalow ?mixed at compile time?
• [ ] add more tests?

This probably needs an RFC, although mixed is already a reserved type. Since I don't have permission to create RFCs, a sponsor would be welcomed (anyone? 😇). Not sure whether it'd be too late for inclusion in 7.2 in case it'd be accepted (probably not yet since there's not even a beta yet).

What do you think? 🚢

allow anonymous class objects

<?php
$var = new class {
    public $data;

    public function __construct($data) {
        $this->data = $data;
    }
} ("Hello World");

var_dump($var);

interface IObject {
    public function iMethod();
}

function my_function(IObject $object) {
    return $object->iMethod();
}

var_dump(my_function(new class implements IObject {
    public function iMethod() {
        return __METHOD__;
    }
}));
?>

Thoughts ??

Description

PHP 7.4.27 / 8.0.15 / 8.1.3 Apache 2.4.52 OpenBSD 7.0 / amd64

If running any of the above PHP versions under Apache (as module), I noticed that every time when apache rotate it's logs it crashes. To be sure of this issue I set the log rotation at a fixed hour (not by size). In the last 3 days, each day at the exactly same hour apache crashed and did not crashed in the rest. Finally I did not loaded the opcache.so and it did not crashed on log rotation. After further investigation I noticed this:

The problem is somwehere in opcache.so. All the above versions are affected. The PHP 7.3.33 works OK, it does not crash.

How to reproduce the issue:

1. load the opcache.so PHP extensions
2. apachectl2 graceful OR kill -HUP 12345 (where 12345 is the process ID number)
3. apache crashes

If I do not load opcache.so it does not crashes.

PHP Version

8.0.15

Operating System

OpenBSD 7.0

Consumes PR #931

This PR allows this to be possible:

namespace Foo 
{
    private class Bar
    {
        // ...
    }
}

namespace Woo {
    class Fuzz extends Bar {}
}

To not be allowed as library developer of Foo may not have planned extension points in class Bar.

RFC to be written yet...

Implementation progress:

• [x] Add lexical support for public classes, traits and interfaces
• [x] Make sure public classes, traits and interfaces are supported correctly
• [x] Add lexical support for private classes, traits and interfaces
• [x] Implement compile time checks for private extension and implementation
• [x] Implement run time check for private class instantiation
• [x] Find a sponsor to review and help polish implementation (Nikita Popov)
• [x] Implement ReflectionClass::isPublic() and ReflectionClass::isPrivate()
• [x] Implement ReflectionClass::setAccessible()

Add more tests coverage for:

ReflectionClass:

• [x] Add test for ReflectionClass::isPublic() with implicit value
• [x] Add test for ReflectionClass::isPublic() with explicit value
• [x] Add test for ReflectionClass::isPrivate() with explicit value
• [x] Add test for ReflectionClass::setAccessible()

Classes:

• [x] Top level private class, top level instantiation
• [x] Top level private class, top level class instantiation
• [x] Top level private class, top level function instantiation
• [x] Top level private class, top level closure instantiation
• [x] Top level private class, top level clone instantiation
• [x] Top level private class, top level class extension
• [x] (FAIL) Top level private class, different namespace instantiation
• [x] Top level private class, different namespace class instantiation
• [x] Top level private class, different namespace function instantiation
• [x] Top level private class, different namespace closure instantiation
• [x] (FAIL) Top level private class, different namespace clone instantiation
• [x] Top level private class, different namespace class extension
• [x] Namespaced private class, top level instantiation
• [x] Namespaced private class, top level class instantiation
• [x] Namespaced private class, top level function instantiation
• [x] Namespaced private class, top level closure instantiation
• [x] (FAIL) Namespaced private class, top level clone instantiation
• [x] Namespaced private class, top level class extension
• [x] (FAIL) Namespaced private class, same namespace instantiation
• [x] Namespaced private class, same namespace class instantiation
• [x] Namespaced private class, same namespace function instantiation
• [x] Namespaced private class, same namespace closure instantiation
• [x] Namespaced private class, same namespace clone instantiation
• [x] Namespaced private class, same namespace class extension
• [x] (FAIL) Namespaced private class, different namespace instantiation
• [x] Namespaced private class, different namespace class instantiation
• [x] Namespaced private class, different namespace function instantiation
• [x] Namespaced private class, different namespace closure instantiation
• [x] (FAIL) Namespaced private class, different namespace clone instantiation
• [x] Namespaced private class, different namespace class extension
• [x] Any of the above test using autoloading

Interfaces:

• [x] Top level private interface, top level class implementation
• [x] Top level private interface, different namespace class implementation
• [x] Namespaced private interface, top level class implementation
• [x] Namespaced private interface, same namespace class implementation
• [x] Namespaced private interface, different namespace class implementation
• [x] Any of the above test using autoloading

Traits:

• [x] Top level private trait, top level class usage
• [x] Top level private trait, different namespace class usage
• [x] Namespaced private trait, top level class usage
• [x] Namespaced private trait, same namespace class usage
• [x] Namespaced private trait, different namespace class usage
• [x] Any of the above test using autoloading

Zend signal handling was added in PHP 5.4 to protect against signal handlers running at inopportune times and causing bugs. The details are in this RFC: https://wiki.php.net/rfc/zendsignals

In short, the handlers for 7 signals of concern are saved and replaced with a generic handler which delegates to the specific handlers. Inside 'critical sections', however, the generic handler puts all information regarding a signal on a queue and just returns. At the end of the critical section, all pending signals on the queue are processed and the specific handlers are called.

However, in PHP 7.1, the vm_interrupt flag was added which also protects against script execution timeouts, etc. occurring at wrong times. This eliminated most of the use cases of Zend signal handling. The one which has remained until now is accessing shared memory in OPCache. By eliminating the use of Zend signal handling there, there will be no need for Zend signal handling any more and a subsystem can be removed. This will make the codebase smaller and easier to understand.

The funny thing about the whole idea of Zend signal handling is... it seems to duplicate what Unix kernels already do. Each process/thread in Unix already has a signal mask which can be used to block signals from being delivered at inopportune times. If a signal arrives when it is masked, the kernel will store it and only deliver it once it is unmasked. So rather than storing signals on a queue and unqueueing them later, we can just let the kernel to its job.

Hi everyone,

This is my first PR for this project. It contains support for CMS, which is RFC 5652. The code borrows heavily from earlier work, because mostly speaking CMS is an incremental upgrade of PKCS#7. The notable changes are these:

• PKCS7 struct to CMS_ContentInfo
• Some internalizing of tests (e.g, they're shoved down to OpenSSL)
• change in the field size for flags

CMS is not present in all versions of OpenSSL. Notably Apple is doing something funky these days with LibreSSL. No idea how they are compiling PHP, but if a dependency is required, it is not yet in this PR.

The fibers PR neglected to import the AIX-specific code from Boost's contexts library. This PR reinstates them and adds them to autoconf.

May be required for non-_CALL_ELF==2 Linux, since that shares the AIX ABI (like, pretty much every non-LE enterprise distro, i.e. EL7).

As suggested by cmb69, this is fixed by changing zend_gcvt() and verifying whether the callers have enough buffer space. The only place that did not allocate enough buffer space was in php_encoding.c. However, it actually uses safe_emalloc with an offset of MAX_LENGTH_OF_DOUBLE + 1 so it wouldn't have overflowed in practice I guess, but I think it's still better to not rely on the overflow protection and do it properly.

Description

The following code:

<?php

function is_assoc($array)
{
    if (!is_array($array) || array() === $array) return false;
    return array_keys($array) !== range(0, count($array) - 1);
}

function bugRepro($xml)
{
    $elements = get_object_vars($xml);
    $elementNames = array_keys($elements);

    if (is_assoc($elements)) {
        foreach ($elementNames as $elementName) {
            bugRepro($xml->{$elementName});
        }
    }
}

$xmlData = <<<EOF
<?xml version="1.0" encoding="utf-8"?>
<document>
	<author name="Doesn't matter" />
	<summary>Segmentation fault happens here</summary>
	<description>Not reached</description>
	<category>Not reached</category>
</document>
EOF;

$xml = simplexml_load_string($xmlData, 'SimpleXMLElement', LIBXML_NOCDATA);
bugRepro($xml);
print("OK" . PHP_EOL);

Resulted in this output:

php: /tmp/php-build/source/8.2.0/Zend/zend_builtin_functions.c:763: zif_get_object_vars: Assertion `!(((__ht)->u.flags & (1<<2)) != 0)' failed.
Aborted

But I expected this output instead:

OK

This bug affects PHP 8.2.0 but not PHP 8.1.13.

PHP 8.2.0 was compiled with the following configure options:

--enable-sockets
--enable-exif
--with-zlib
--with-zlib-dir=/usr
--with-bz2
--enable-intl
--with-openssl
--enable-soap
--enable-xmlreader
--with-xsl
--enable-ftp
--enable-cgi
--with-curl=/usr
--with-tidy
--enable-sysvsem
--enable-sysvshm
--enable-shmop
--with-mysqli=mysqlnd
--with-pdo-mysql=mysqlnd
--with-pdo-sqlite
--enable-pcntl
--with-readline
--enable-mbstring
--enable-debug
--enable-fpm
--enable-bcmath
--enable-phpdbg
--with-webp
--enable-gd
--with-jpeg
--with-zip
--with-mhash

PHP Version

PHP 8.2.0

Operating System

Ubuntu 22.04

Additional Information

Here's the line in the PHP source code where the assertion error happens: https://github.com/php/php-src/blob/PHP-8.2.0/Zend/zend_builtin_functions.c#L763

Description

fgets() sometimes does not read a full line.

I'm reading old style fixed format ASCII files using PHP 8.0.26 (from the official docker image). The file only contains [a-zA-Z0-9], spaces and newlines. Every line in the file is exactly 559 characters long. The file gets downloaded to a local file system before the file is opened.

<?php
          ...
          if ($file = fopen($real_directory . '/' . $content, "r")) {
            $line_nr = 0;
            while (!feof($file)) {
              $line_nr++;
              $line = rtrim(fgets($file));
              // Get some fields from $line using substr().
            }
            fclose($file);
          }

Once every about 300K lines a line is not completely read into $line, and the substr() fails to get the data I expect: at a specific location in each line there's either the keyword 'IMPORTED' or 'REJECTED'. If that happens the code stops (by intention) as something would be wrong with the input file. Afterwards when I look at the "corrupted" file, the file is completely normal: no escape characters, nothing out of the ordinary. When I reprocess the file unchanged, it goes through without complaining (finding for the line with the latter problem the proper keyword).

I see it happening (although seldom), and I can't replicate it consistently.

PHP Version

PHP 8.0.26

Operating System

Debian GNU/Linux 11 (bullseye)

As described on the mailing list, Zend Signals cause segmentation faults and other problems in multi-threaded environments.

We already disabled Zend Signals for ZTS builds of the official Docker images: https://github.com/docker-library/php/pull/1331 Similarly, this patch disables Zend Signals by default for ZTS build to prevent these issues. It's still possible to enable Zend Signals explicitly with --enable-zend-signals

Description

This is a very serious bug that may impact all strings in PHP.

The following code:

<?php

ini_set('display_errors', '1');	// display runtime errors
error_reporting(E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED); // error reporting
date_default_timezone_set('UTC');

function detect_encoding($ystr, $csetlist='UTF-8, ISO-8859-1, ISO-8859-15, ISO-8859-2, ISO-8859-9, ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-10, ISO-8859-13, ISO-8859-14, ISO-8859-16, UTF-7, ASCII, SJIS, EUC-JP, JIS, ISO-2022-JP, EUC-CN, GB18030, ISO-2022-KR, KOI8-R, KOI8-U') {
	return mb_detect_encoding((string)$ystr, (string)$csetlist, true); // mixed: (bool) FALSE or (string) 'CHARSET'
}

echo detect_encoding('A + B'); // expected output: UTF-8, but on PHP 8.1.x / 8.2.x returns UTF-7 if the '+' character is present in a string ; the PHP 8.0.x and 7.4.x behaves correctly and outputs UTF-8 also in this case
echo "\n";
echo detect_encoding('A - B'); // expected output: UTF-8 ; correct on all PHP versions 8.2.x / 8.1.x / 8.0.x / 7.4.x

Resulted in this output ; On PHP 8.2 and 8.1, if the plus (+) character is present in a string will detect UTF-7 instead of UTF-8 as expected:

UTF-7
UTF-8

But I expected this output instead ; on PHP 7.4 and PHP 8.0 works correctly. Output is this):

UTF-8
UTF-8

I tested here with different PHP versions. https://onlinephp.io/ I also tested in my computer with PHP 8.1.12 and 8.0.25

PHP Version

8.1.x / 8.2.x

Operating System

All