* PHP-8.2:
NEWS for GH-14814
ext/standard/tests: strings/wordwrap_memory_limit_32bit.phpt has two outputs
ext/standard/tests: 32bit wordwrap tests aren't just for Windows
It turns out that on a 32-bit system, this test can produce either the
"usual" expected output from the 64-bit test, OR the 32-bit-only
integer overflow message. We copy the dual expected outputs from
chunk_split_variation1_32bit.phpt to handle both cases.
This fixes an earlier commit that split the two tests based only on
the size of an int (32-bit versus 64-bit). The CI reveals that, at
least on a debug/zts build, the "64-bit" memory limit error (and not
the integer overflow error) is still produced.
The test in strings/wordwrap_memory_limit.phpt has a counterpart in
strings/wordwrap_memory_limit_win32.phpt. The two are conditional on
both the OS name and the size of an int (32- versus 64-bits).
A Gentoo Linux user has however reported that the 64-bit test fails on
a 32-bit system, with precisely the error message that the "win32"
test is expecting. I don't have any 32-bit hardware to test myself,
but I think it's reasonable to conclude that the OS name is not an
essential part of the test: it's simply 32- versus 64-bit.
This commit drops the conditionals for the OS name. Now one test will
be run on 32-bit systems, and the other on 64-bit systems, regardless
of the OS name.
Bug: https://bugs.gentoo.org/935382
In strings/chunk_split_variation1_32bit.phpt, we have a test that is
expected to fail on x32 with a possible integer overflow error. The
message reports the exact number of bytes -- a number big enough to
overflow an int on x32 -- stemming from a memory allocation in
chunk_split().
This number appears unpredictable, and is not the point of the test.
We replace it with %d to make the test independent of the allocation
details.
There's a test that tries to make /etc world-writable, and asserts that
it fails. Although this test is guarded by a root user check, there are
situations where you don't need to be root to be able to do this.
This may thus have unwanted effects on your live filesystem.
The simple solution is to remove that part of the test. It doesn't
really add value anyway: we're trying to test the chmod error path, but
that exact same error path can be reached with any failure condition
that the kernel gives. For example, trying to chmod a non-existent file
will trigger the same code path.
While at it, also prefix the test path for the non-existent file such
that we don't accidentally modify the filesystem.
The chroot now has a better root-user check, that will not modify the
filesystem.
Other root-modifying mkdir tests were removed because they added no
value either.
Closes GH-13566.
The array isn't just observable if the array has RCn, but also if it is inside a
reference that is RCn. By-ref parameters are always RCn and as such always
observable.
Fixes GH-13279
Closes GH-13285
Joe Cai