The PHP Interpreter
Other
34369
1439
7332

Description

The following code:

<?php
copy("test.txt", "testcopy.txt");

Resulted in this output:
testcopy.txt is an empty 0 bytes file.

But I expected this output instead:
testcopy.txt is a copy of test.txt

The following workaround is working:

<?php
file_put_contents("testcopy.txt", file_get_contents("test.txt"));

This problem exists at least since PHP 8.2.0-rc1. Production versions such as PHP 8.1.11 are working as expected. I am using Debian 10 with the packages provided by https://deb.sury.org running in a VirtualBox machine.

PHP Version

PHP 8.2.0-rc3

Operating System

Debian 10

Description

There seems to be some inconsistent behavior with Disjunctive Normal Form Types when an argument has a default value of null.

Usually if the default value is null, the argument is implicitly nullable, eg:

<?php
function foo(string $param = null) { var_dump($param); }
function bar(\Foo\Bar|\Foo\Baz $param = null) { var_dump($param); }

foo(null);
bar(null);

result:

NULL
NULL

https://3v4l.org/iBlne

An exception to this rule are PHP 8.1 intersection types:

function foo(\Foo\Bar&\Foo\Baz $param = null) { var_dump($param); }

foo(null);

result:

Fatal error: Cannot use null as default value for parameter $param of type Foo\Bar&Foo\Baz in /in/k0OjD on line 3

Process exited with code 255.

https://3v4l.org/k0OjD

However, the same error is raised on PHP 8.2, even though the following works:

function foo((\Foo\Bar&\Foo\Baz)|\Foo\Qux $param = null) { var_dump($param); }

foo(null);

result:

NULL

https://3v4l.org/UADDP

With the introduction of DNF types, I would expect \Foo\Bar&\Foo\Baz $param = null to implicitly mean (\Foo\Bar&\Foo\Baz)|null $param = null, which works as expected:

function foo((\Foo\Bar&\Foo\Baz)|null $param = null) { var_dump($param); }

foo(null);

result:

NULL

https://3v4l.org/gjOAp

PHP Version

PHP 8.2rc3

Operating System

Ubuntu 22.04

Description

The following tests are failing on s390x arch and with 8.1.11 release on armv7 of stable 3.16 release:

FAILED TEST SUMMARY
---------------------------------------------------------------------
Handling of errors during linking [ext/opcache/tests/preload_006.phpt]
Argument/return types must be available for preloading [ext/opcache/tests/preload_011.phpt]

This is 3.16 stable release of Alpinelinux
Resulted in this output:

armv7

========DIFF========
[1;32m001+ mmap() failed: [12] Out of memory[0m
[1;31m001- Warning: Can't preload unlinked class B: Declaration of B::foo($bar) must be compatible with A::foo() in %spreload_inheritance_error.inc on line 8[0m
[1;31m002- Foobar[0m
========DONE========
[1;31mFAIL[0m Handling of errors during linking [ext/opcache/tests/preload_006.phpt] 

========DIFF========
[1;32m001+ mmap() failed: [12] Out of memory[0m
[1;31m001- Warning: Can't preload unlinked class H: Could not check compatibility between H::method($a): L and G::method($a): K, because class L is not available in %spreload_variance.inc on line 43[0m
========DONE========
[1;31mFAIL[0m Argument/return types must be available for preloading [ext/opcache/tests/preload_011.phpt] 

s390x is

========DIFF========
[1;32m001+ Termsig=0[0m
[1;31m001- Warning: Can't preload unlinked class B: Declaration of B::foo($bar) must be compatible with A::foo() in %spreload_inheritance_error.inc on line 8[0m
[1;31m002- Foobar[0m
========DONE========
[1;31mFAIL[0m Handling of errors during linking [ext/opcache/tests/preload_006.phpt] 

========DIFF========
[1;32m001+ Termsig=0[0m
[1;31m001- Warning: Can't preload unlinked class H: Could not check compatibility between H::method($a): L and G::method($a): K, because class L is not available in %spreload_variance.inc on line 43[0m
========DONE========
[1;31mFAIL[0m Argument/return types must be available for preloading [ext/opcache/tests/preload_011.phpt] 

But I expected this will fail only om s390x arch
and then faced with https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/39622#note_265884

PHP Version

8.1.11

Operating System

Alpinelinux 3.16

Description

CI report: https://github.com/php/php-src/actions/runs/3160522498/jobs/5145079204#step:8:110

here is commit /w Windows CI to reproduce: 37498f9

it seems there is some core problem not specific to the failed test, as later absolutely unrelated push https://github.com/php/php-src/compare/37498f95b5b26d47a03b74b0dcc062d545195a0c..3adb2737355882b3d808cf53630d304374d5bf7e did not produce it. and in another pushes I saw another failed tests like in #8643 and #8450...

PHP Version

PHP 8.0 and probably 8.1+ too

Operating System

Windows x86/32 bit

Description

Reproducible /w https://github.com/php/php-src/blob/PHP-8.0/ext/soap/tests/interop/Round4/GroupH/r4_groupH_simple_rpcenc_002w.phpt test

see https://github.com/php/php-src/runs/6289390413?check_suite_focus=true#step:8:3238

========DIFF========
001+ Can't initialize heap: [0x000001e7] Attempt to access invalid address

002+ 

003+ Termsig=-1073741819

001- <?xml version="1.0" encoding="UTF-8"?>

002- <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://soapinterop.org/wsdl" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><ns1:echoStringFault><param xsi:type="xsd:string">Hello World</param></ns1:echoStringFault></SOAP-ENV:Body></SOAP-ENV:Envelope>

003- <?xml version="1.0" encoding="UTF-8"?>

004- <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns1="http://soapinterop.org/wsdl" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><SOAP-ENV:Fault><faultcode>SOAP-ENV:Server</faultcode><faultstring>Fault in response to 'echoStringFault'.</faultstring><detail><ns1:part2 xsi:type="xsd:string">Hello World</ns1:part2></detail></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope>

005- ok
========DONE========

PHP Version

latest 8.0

Operating System

Windows, probably also linux, x86/32b target arch

Description

code https://github.com/php/php-src/blob/9b8f76bfa29ff234ff45a27b8171e13c9b8d2928/ext/spl/tests/bug77263.phpt
CI: https://github.com/mvorisek/php-src/runs/6201706203?check_suite_focus=true#step:8:3851

========DIFF========
001+ Can't initialize heap: [0x000001e7] Attempt to access invalid address

001- OK

002+ 

003+ Termsig=-1073741819
========DONE========
FAIL Bug #77263 (Segfault when using 2 RecursiveFilterIterator) [D:\a\php-src\php-src\ext\spl\tests\bug77263.phpt] 

for some reasons, this issue is not always present

PHP Version

8.x, probably master too

Operating System

Windows 32-bit

Description

I'm embedding PHP in a Go program. When this program receives SIGINT, PHP crashes with the following stack trace (extracted using GDB):

Thread 1 "internal" received signal SIGSEGV, Segmentation fault.
0x00000000007b907c in zend_signal_handler_defer (signo=2, siginfo=0xffffeb3e5600, context=0xffffeb3e5680) at /go/php-src/Zend/zend_signal.c:98
98              if (EXPECTED(SIGG(active))) {

This may be related to #8029, #8789, #9337.

If anyone has an idea of what's happening, I can give them access to a private repository with a simple way to reproduce the crash. I reproduced the issue on Debian and macOS.

Go documentation about signal handling and C code: https://pkg.go.dev/os/signal#hdr-Go_programs_that_use_cgo_or_SWIG

PHP Version

PHP 8.2-dev

Operating System

Debian, macOS

Description

The following code:

<?php

$fds = [];
for ($i = 0; $i < 1023; $i++) {
    $fds[] = fopen("/tmp/__0_a_evil_tmpfile.$i", 'w');
}

list($a, $b) = stream_socket_pair(STREAM_PF_UNIX, STREAM_SOCK_STREAM, STREAM_IPPROTO_IP);

$r = [$a];
$w = $e = [];
var_dump(stream_select($r, $w, $e, PHP_INT_MAX));

Will result in a hang, after printing the warning, with an empty select() syscall being emitted.

However, adding in an error handler throwing an exception, e.g. set_error_handler(function() { throw new \Exception; }); at the start will cause the warning not be printed and still hang indefinitely, hiding the issue very well.

(Original bug report at amphp/amp#398)

PHP Version

PHP 7.4 - master

Operating System

No response

Description

The following code:

<?php
file_put_contents("/proc/1/fd/1", "hi");

Resulted in this output:

file_put_contents(/proc/1/fd/1): failed to open stream: No such file or directory

But I expected this output instead:

2

This is highly impactful for containerized PHP environments. php-fpm has unique workarounds that they've utilized, and in the past the fd stream wrapper was implemented to support managing the current process's file descriptors, but if you are in a different SAPI and/or utilize forking or execing to other PHP scripts, stdout in a docker container quickly turns into a black hole in terms of container logging, where it's expected that all logs are sent to the PID 1 stdout/err. See: https://bugs.php.net/bug.php?id=53465 where they hypothesize this is due to PHP incorrectly attempts to dereference the pseudo-symlink before opening it. The hypothesis makes sense to me. It'd be nice to see this fixed for all file descriptors.

PHP Version

7.4

Operating System

Centos 7.9

Description

Opcache saves values from ini_get() for PHP_INI_SYSTEM type directives in the opcache when optimization is enabled.
This is a problem when a shared file uses ini_get() for PHP_INI_SYSTEM.

Example of this is a server with multiple virtual hosts where the sites use a common/shared framework.
The framework has an image uploading part where it fetches the upload_tmp_dir setting from ini to use a place for temporary image manipulations.
The virtual hosts are set up using PHP_ADMIN_VALUE to set a specific upload folder for each site.

fastcgi_param PHP_ADMIN_VALUE "upload_tmp_dir=/tmp/uploads/site1";

In this scenario the framework uses ini_get('upload_tmp_dir') to get the tmp folder value, but the value it gets is always the value for the first site that included that php file. So if site "foo.example.com" was first, then ALL other sites will get the upload_tmp_dir from "foo.example.com".

I reproduced this in all versions >=7.2, and for cli, fpm and mod_php.

Security

Not sure this counts as a security problem but this means that information could leak between sites.

Note that using PHP_ADMIN_VALUE for any option results in this problem.

Ways to reproduce:

Setup php files
mkdir /tmp/test/ && cd /tmp/test/
echo '<?php echo "S: " . ini_get("upload_tmp_dir") . "\n";' > shared.php
echo '<?php echo "1: " . ini_get("upload_tmp_dir") . "\n"; include "./shared.php";' > 1.php
echo '<?php echo "2: " . ini_get("upload_tmp_dir") . "\n"; include "./shared.php";' > 2.php
Cli

Create a cli-opcache.ini file in the "scan" additional .ini files directory:

zend_extension=opcache.so
[opcache]
opcache.enable=1
opcache.enable_cli=1
opcache.file_cache="/tmp/php-file-cache"
opcache.file_cache_only=1
opcache.file_cache_consistency_checks=1

Create file cache folder

mkdir /tmp/php-file-cache

Run the test

php -d upload_tmp_dir=/tmp/num1 /tmp/test/1.php
php -d upload_tmp_dir=/tmp/num2 /tmp/test/2.php

Expected result:

1: /tmp/num1
S: /tmp/num1
2: /tmp/num2
S: /tmp/num2

Actual result:

1: /tmp/num1
S: /tmp/num1
2: /tmp/num2
S: /tmp/num1
nginx + fpm

Make sure that opcache with optimizations is enabled.

Setup two virtual hosts and reload nginx:

server {
    listen 80; 
    server_name p1; 
    root /tmp/test; 
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
	    fastcgi_pass   127.0.0.1:9000;
	    fastcgi_param  PHP_ADMIN_VALUE "upload_tmp_dir=/tmp/cache1";
    }
}
server {
    listen 80; 
    server_name p2; 
    root /tmp/test; 
    location ~ \.php$ {
	    include snippets/fastcgi-php.conf;
	    fastcgi_pass   127.0.0.1:9000;
	    fastcgi_param  PHP_ADMIN_VALUE "upload_tmp_dir=/tmp/cache2";
    }
}

Run the tests:

curl --resolve p1:80:127.0.0.1 http://p1/1.php
curl --resolve p2:80:127.0.0.1 http://p2/2.php

Expected result:

1: /tmp/cache1
S: /tmp/cache1
2: /tmp/cache2
S: /tmp/cache2

Actual result:

1: /tmp/cache1
S: /tmp/cache1
2: /tmp/cache2
S: /tmp/cache1

Workarounds

For me, I ended up with changing the shared framework, and now have to maintain my own fork of it.

You can turn off opcache optimizations.

Another way to work around this is to compile php yourself, with removing the ini_get if block, or even just
changing ini_get to ini_get_opcache_workaround in the zend_optimizer_eval_special_func_call function
in Zend/Optimizer/zend_optimizer.c.

PHP Version

7.2.0 - 8.1.6

Operating System

No response

Description

The following code:

<?php
print("enable_dl: ".ini_get("enable_dl"));
dl("xml.so");

Resulted in this output:

enable_dl: 1
Warning: Module "xml" is already loaded in Unknown on line 0
Segmentation fault (core dumped)

But I expected this output instead:

enable_dl: 1
Warning: Module "xml" is already loaded in Unknown on line 0

Working example:

% php --version
PHP 8.1.10 (cli) (built: Sep 16 2022 15:09:44) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.10, Copyright (c) Zend Technologies
% php -m
[PHP Modules]
Core
date
hash
json
libxml
mysqlnd
openssl
pcre
Reflection
SPL
standard
xml
zlib

[Zend Modules]
% cat > sigsegv.php <<EOF
? <?php
? print("enable_dl: ".ini_get("enable_dl"));
? dl("xml.so");
? EOF
% php sigsegv.php
enable_dl: 1
Warning: Module "xml" is already loaded in Unknown on line 0

Failing example:

% php --version
PHP 8.2.0RC2 (cli) (built: Sep 20 2022 20:24:30) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.0RC2, Copyright (c) Zend Technologies
% php -m
[PHP Modules]
Core
date
hash
json
libxml
mysqlnd
openssl
pcre
random
Reflection
SPL
standard
xml
zlib

[Zend Modules]

% cat > sigsegv.php <<EOF
? <?php
? print("enable_dl: ".ini_get("enable_dl"));
? dl("xml.so");
? EOF
% php sigsegv.php
enable_dl: 1
Warning: Module "xml" is already loaded in Unknown on line 0
Segmentation fault (core dumped)
% lldb --core php.core  /usr/local/bin/php
(lldb) target create "/usr/local/bin/php" --core "php.core"
Core file '/tmp/php.core' (x86_64) was loaded.
Could not load history file
(lldb) bt all
* thread #1, name = 'php', stop reason = signal SIGSEGV
  * frame #0: 0x00000000006939c3 php`___lldb_unnamed_symbol3142$$php + 19
    frame #1: 0x000000000069b396 php`zend_hash_apply_with_argument + 118
    frame #2: 0x000000000068e884 php`___lldb_unnamed_symbol3137$$php + 84
    frame #3: 0x000000000069ac68 php`zend_hash_graceful_reverse_destroy + 536
    frame #4: 0x0000000000683cc8 php`___lldb_unnamed_symbol3117$$php + 24
    frame #5: 0x000000000060c189 php`php_module_shutdown + 41
    frame #6: 0x0000000000772858 php`___lldb_unnamed_symbol4788$$php + 696
    frame #7: 0x0000000000418fe0 php`_start + 256
(lldb)

It looks like a regression to me from 8.1 to 8.2.

PHP Version

PHP 8.2.0 RC2

Operating System

FreeBSD: 12.3-RELEASE-p7

Setup

Clean Poudriere throwaway Jails from FreeBSD ports, main branch.

Description

When compiling PHP 8.2 on Mac OS X with the following configuration:

./configure --enable-embed=static --enable-zts --with-iconv=/opt/homebrew/opt/libiconv/ --enable-opcache

I get this error when loading the opcache.so extension:

Failed loading /usr/local/lib/php/extensions/no-debug-zts-20220829/opcache.so: dlopen(/usr/local/lib/php/extensions/no-debug-zts-20220829/opcache.so, 0x0009): symbol not found in flat namespace (_zend_gdb_register_code)

Disabling opcache JIT fixes the issue:

./configure --enable-embed=static --enable-zts --with-iconv=/opt/homebrew/opt/libiconv/ --enable-opcache --disable-opcache-jit

PHP Version

PHP 8.2-dev

Operating System

macOS 12.6

Description

Hi, I maintain a PHP extension and recognize after the embedding of the PHP autoconf extension a bug in the makefile:

> grep -- '-g\>' Makefile
CFLAGS = -g g -Wall -Wcast-align -Wfatal-errors -O0
CXXFLAGS = -g g -Wall -Wcast-align -Wfatal-errors -g -O0

→ as you see the -g g is invalid, the question is: where it comes from ?

I add some debug prints into the configure and end up with:

checking if debug is enabled... yes
checking if zts is enabled... no
44 ++++++++++++++++++++ CFLAGS=-g -Og -Wall -Wcast-align -Wfatal-errors
55 ++++++++++++++++++++ CFLAGS=-g g -Wall -Wcast-align -Wfatal-errors
checking for gawk... gawk
checking for 'ZTS'... no

the problem in configure was the SED ... it does NOT recognize the -Og option :

if test "$PHP_DEBUG" = "yes"; then
  PHP_DEBUG=1
  ZEND_DEBUG=yes

echo "44 ++++++++++++++++++++ CFLAGS=$CFLAGS"

  CFLAGS=`echo "$CFLAGS" | $SED -e 's/-O[0-9s]*//g'`
  CXXFLAGS=`echo "$CXXFLAGS" | $SED -e 's/-O[0-9s]*//g'`

echo "55 ++++++++++++++++++++ CFLAGS=$CFLAGS"

    if test "$GCC" = "yes" || test "$ICC" = "yes"; then
    CFLAGS="$CFLAGS -O0"
    CXXFLAGS="$CXXFLAGS -g -O0"
  fi
  if test "$SUNCC" = "yes"; then
    if test -n "$auto_cflags"; then
      CFLAGS="-g"
      CXXFLAGS="-g"
    else
      CFLAGS="$CFLAGS -g"
      CXXFLAGS="$CFLAGS -g"
    fi
  fi
else
  PHP_DEBUG=0
  ZEND_DEBUG=no
fi

the source is from configure.ac created by phpize

PHP Version

PHP 8.1.10

Operating System

openSUSE Tumbleweed

Description

Experimenting with the sample embed sapi code and build instructions from the provided readme. I also have the tokenizer extension installed. The php cli sapi works just fine. And php -m reports the tokenizer extension loaded. However, the embed sapi throws a warning about being unable to load tokenizer due to an undefined symbol, zend_ce_stringable. I suspect other extensions that utilize this class will also fail to load in the same way.

Any ideas what am I missing here? This might not be a bug (apologies if not), but I'm just not seeing what isn't being loaded to make tokenizer happy. Feels like a bug or a documentation oversight. Will poke at it some more tomorrow.

FreeBSD main, PHP 8.1.10

PHP Version

PHP 8.1.10

Operating System

FreeBSD main

Description

Hi,
at the first - thank for your job.

About issue: we use PHP 8.1.9 in k8s + prometheus.
Now we try to migrate from hipages/php-fpm_exporter:2.2.0-amd64 (https://github.com/hipages/php-fpm_exporter) to https://www.php.net/manual/en/fpm.status.php

https://localhost/fpm-status?full - this route returns all data what we want to track/monitor.
We use prometheus.
So, we try to read fpm-status in prometheus format.

https://localhost/fpm-status?openmetrics - this route returns some.
https://localhost/fpm-status?openmetrics&full - this route returns the same data like from https://localhost/fpm-status?openmetrics. It's mean that we can't see additional (like in https://localhost/fpm-status?full).

Looks like is expected behavior according with https://github.com/php/php-src/blob/master/sapi/fpm/fpm/fpm_status.c#L431 -
full_syntax = "";

Do have any plans about setting/adding correct data for case with prometheus format (like for TEXT - https://github.com/php/php-src/blob/master/sapi/fpm/fpm/fpm_status.c#L456)?

Thank you

Description

I just recognized a problem in a project when testing it with PHP 8.2RC2 (API Platform 3.0).

There is an interface that contains a method with the return type definition "object|iterable|null". In PHP 8.2 "iterable" becomes "array|Traversable" and so the return type definition results in "object|array|Traversable|null", which now contains the redundant "Traversable" type (although "object" is already contained) and leads to a fatal error.

Eample...

The following code:

<?php
class Foo
{
    public function bar(): object|iterable|null
    {
        return null;
    }
}

echo 'baz';

Resulted in this output:

Fatal error: Type Traversable|object|array|null contains both object and a class type, which is redundant in [...

But I expected this output instead:

baz

As a workaround one could use "object|array" instead of "object|iterable", but best would be if the change in PHP 8.2 handles this special case, to avoid this break... Otherwise this should be listed in "Backward Incompatible Changes" instead of "Other Changes".

PHP Version

PHP 8.2.0RC2

Operating System

No response

Description

The following code:

<?php

$db = new PDO(...);

$sql = <<<SQL
    CREATE TABLE test (
        `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
        `birthday` DATE NOT NULL,
        `name` VARCHAR(40) NOT NULL,
        `salary` INT NOT NULL,
        `boss` BIT NOT NULL
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8
SQL;

$query = $db->prepare($sql);
$query->execute();

$sql = <<<SQL
    INSERT INTO test
    (birthday, name, salary, boss)
    VALUES (:birthday, :name, :salary, :boss)
SQL;

$query = $db->prepare($sql);

$staff = [
    [
        'birthday' => (new DateTime('1995-05-01'))->format('Y-m-d'),
        'name' => 'Sharon',
        'salary' => '200',
        'boss' => TRUE,
    ],
];

foreach ($staff as $member) {
/* works
    $query->bindValue('birthday', $member['birthday'], PDO::PARAM_STR);
    $query->bindValue('name', $member['name'], PDO::PARAM_STR);
    $query->bindValue('salary', $member['salary'], PDO::PARAM_INT);
    $query->bindValue('boss', $member['boss'], PDO::PARAM_BOOL);
    $query->execute();
*/
    // does not work
    $query->execute($member);
}

Resulted in this output:

SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'boss' at row 1

But I expected execute() not to throw an error.

I clearly see the problem in the source as the parameter is always set to be a string on line 424:

php-src/ext/pdo/pdo_stmt.c

Lines 411 to 425 in 615b800

ZEND_HASH_FOREACH_KEY_VAL(Z_ARRVAL_P(input_params), num_index, key, tmp) {
memset(&param, 0, sizeof(param));
if (key) {
/* yes this is correct. we don't want to count the null byte. ask wez */
param.name = key;
param.paramno = -1;
} else {
/* we're okay to be zero based here */
/* num_index is unsignend */
param.paramno = num_index;
}
param.param_type = PDO_PARAM_STR;
ZVAL_COPY(&param.parameter, tmp);

Can't the execute() code be improved to check for the param type like it is done in bindValue()?

php-src/ext/pdo/pdo_stmt.c

Lines 1465 to 1475 in 615b800

memset(&param, 0, sizeof(param));
ZEND_PARSE_PARAMETERS_START(2, 3)
Z_PARAM_STR_OR_LONG(param.name, param.paramno)
Z_PARAM_ZVAL(parameter)
Z_PARAM_OPTIONAL
Z_PARAM_LONG(param_type)
ZEND_PARSE_PARAMETERS_END();
PHP_STMT_GET_OBJ;
param.param_type = (int) param_type;

PHP Version

8.2.0 RC3

Operating System

Alpine Linux

Description

Hello!

the standard trim() function has a major flaw as it does not cleanup multibyte spaces.
I see two options to this problem:

  • implement mb_trim()
  • add support for multibyte spaces to the existing function

Code example in php 8.1.8

// does not work
echo var_dump(trim('小野 ')); // string(9) "小野 "

// temporary solution
echo var_dump(preg_replace("/^\s+|\s+$/u", "", "小野 ")); // string(6) "小野"

Description

I don't known if it's problem with chrome 104 (because firefox/vivaldi works) or with php, but is impossible to serve index.html with php 8.0.22 or php 8.1.9 and PHP_CLI_SERVER_WORKERS >2

It's impossible to serve this index.html with php >8.0.2 with PHP_CLI_SERVER_WORKERS >2

Everything works with php7.4.30

The following code:

index.html:

<html>
<script src='test.js?1'></script>
<script src='test.js?2'></script>
<script src='test.js?3'></script>
<script src='test.js?4'></script>
<script src='test.js?5'></script>
<script src='test.js?6'></script>
<script src='test.js?7'></script>
<script src='test.js?8'></script>
<script src='test.js?9'></script>
<script src='test.js?10'></script>
<script src='test.js?11'></script>
<script src='test.js?12'></script>
<script src='test.js?13'></script>
<script src='test.js?14'></script>
<script src='test.js?15'></script>
<script src='test.js?16'></script>
</html>

<body>
Finish...
</body>
  1. create file index.html
  2. start php 8.1.9 PHP_CLI_SERVER_WORKERS=2 php8.1 -S localhost:8081
  3. open http://localhost:8081 in Chrome 104.0.5112.101

PHP Version

8.0.22 , 8.1.9

Operating System

Ubuntu 20.04

Description

I have 2 files with the same class name:
The Users.php have the following:

class User
{
    public string $name = "";

    public function __construct()
    {
        $this->name = 'John Doe';
    }
    
    public function echoName(){
        return $this->name;
    }
}

<?php
include('../class/Users.php');
include('../users/Users.php');

Resulted in this output:

//No error was listed.

But I expected this output instead:

Error - cannot use the same class name
//This is the solution to get the error
<?php
include('../class/Users1.php');
include('../users/Users2.php');

Reload the page gives the appropriate error - cannot use the same class name

//Then using namespaces will fix this error

Since the files are of different paths and in the global namespace I would expect the error to occur but it did not.
Not sure why I have to name the files with different names to get the error which may cause a problem in
instantiating a class.

if you use:

$user = new User();

then no error is shown.

but is does load the second file class if you run

echo $user->echoName();

Shouldn't an error occur with the files named the same name but in a different directory?

PHP Version

PHP 8.1

Operating System

No response