* 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.
The old code checked for suffixes but didn't take into account trailing
whitespace. Furthermore, there is peculiar behaviour with trailing dots
too. This all happens because of the special path-handling code inside
CreateProcessW.
By studying Wine's code, we can see that CreateProcessInternalW calls
get_file_name [1] in our case because we haven't provided an application
name. That code gets the first whitespace-delimited string into app_name
excluding the quotes. It's then passed to create_process_params [2]
where there is the path handling code that transforms the command line
argument to an image path [3]. Inside Wine, the extension check if
performed after these transformations [4]. By doing the same thing in
PHP we match the behaviour and can properly match the extension even in
the given edge cases.
[1] 166895ae3a/dlls/kernelbase/process.c (L542-L543)
[2] 166895ae3a/dlls/kernelbase/process.c (L565)
[3] 166895ae3a/dlls/kernelbase/process.c (L150-L151)
[4] 166895ae3a/dlls/kernelbase/process.c (L647-L654)
Short-lived regression from 5ce9687cb2.
I forgot to add the persistent local flag, so that means that RC_DEBUG
will complain. These strings are local to the thread so we can just add
the flag to silence the debug checker in this case.
The hash tables used are allocated via the persistent allocator.
When using ini_set, the allocation happens via the non-persistent
allocator. When the table is then freed in GSHUTDOWN, we get a crash
because the allocators are mismatched.
As a side note, it is strange that this is designed this way, because it
means that ini_sets persist between requests...
Co-authored-by: Kamil Tekiela <tekiela246@gmail.com>
