It seems that f3efb9e3fb introduced a "typo" which may result
in the following confusing message:
checking for mmap() using MAP_ANON shared memory support... no=yes
Let's fix this.
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
Closes GH-6758.
This issue came up recently in a bug report[1]; without the error code,
users can barely guess why the function failed.
[1] <https://bugs.php.net/80812>
Closes GH-6745.
Don't use r0 as temporary register in math_double_long if it is
already used for a memory result.
This was already done in one branch, but not the other.
When one thread tries to compile a script, another thread may
already be executing JITed code. In this case we can't make the
memory non-executable.
This violates the W^X principle, but doesn't seem to be avoidable
for ZTS builds for now. The same problem does not exist for NTS,
as it's a different process executing there, which has it's own
memory protection mapping.
Closes GH-6595.
* mysqli_commit $flags default value is 0, not -1.
* A number of functions cannot actually return null.
* mysqli_poll parameter names were incorrect, as this function
has a different signature from select.
* fetch functions apart from fetch_all can return false on failure.
`opcache.jit` accepts `tracing` and `function` as aliases, but they were not mentioned in the start-up INI warning message.
This updates the error message to include all possible values.
Closes GH-6490.
Replacing the result type in the general case is dangerous,
because not all opcodes support both VAR and TMP. One common case
is the in_array() result being passed to SEND_VAR, which would
have to be changed to SEND_VAL.
Rather than complicating this logic, reduce the scope to only
doing the type replacement for JMPZ and JMPNZ. The only reason
we're doing this in the first place is to enable the smart branch
optimization, so we can limit it to the relevant opcodes. Replacing
the result type may be marginally useful in other cases as well
(as it may avoid reference checks), but not worth the bother.
We only need to reject functions that could warn (or have runtime
dependent behavior). If a function can throw in some cases, just
let it and discard the result.
We should clear the exception *before* we destroy the execute_data.
Add a variation of the test that indirects through another file,
and would crash otherwise.
