On NixOS, the output of phpinfo() can get very large, causing us to run into the
backtracking limit. Lazy matching for .*/.+ can help reduce backtracking.
We need to avoid signed integer overflows which are undefined behavior.
We catch that, and set `offset` to `ZEND_LONG_MAX` (which is also the
largest value of `zend_off_t` on all platforms). Of course, that seek
may fail, but even if it succeeds, the stream is no longer readable,
but that matches the current behavior for offsets near `ZEND_LONG_MAX`.
Closes GH-15989.
We need to avoid signed integer overflows which are undefined behavior.
We catch that, and set `offset` to `ZEND_LONG_MAX` (which is also the
largest value of `zend_off_t` on all platforms). Of course, after such
a seek a stream is no longer readable, but that matches the current
behavior for offsets near `ZEND_LONG_MAX`.
Closes GH-15989.
This was first reported as a leak in GH-15026, but was mistakingly
believed to be a false positive. Then an assertion was added and it got
triggered in GH-15908. This fixes the leak. Upon merging into master the
assertion should be removed as well.
Closes GH-15924.
We were using atoi, which is only for integers. When the size does not
fit in an integer this breaks. Use ZEND_STRTOUL instead. Also make sure
invalid data isn't accidentally parsed into a file size.
Closes GH-15035.
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.
Commit 5cbe5a538c disabled chunking for all writes to streams. However,
user streams have a callback where code is executed on data that is
subject to the memory limit. Therefore, when using large writes or
stream_copy_to_stream/copy the memory limit can easily be hit with large
enough data.
To solve this, we reintroduce chunking for userspace streams.
Users have control over the chunk size, which is neat because
they can improve the performance by setting the chunk size if
that turns out to be a bottleneck.
In an ideal world, we add an option so we can "ask" the stream whether
it "prefers" chunked writes, similar to how we have
php_stream_mmap_supported & friends. However, that cannot be done on
stable branches.
Closes GH-13136.
005_variation2.phpt creates files with special names, and
filesize_variation5.phpt checks for filesize of inexistent files with special
names. Create the files in a separate directory to avoid these tests clashing.
Closes GH-12692
Arnaud Le Blanc