Fix #79665: ini_get() and opcache_get_configuration() inconsistency
Overriding the given INI values in modifier callbacks is not possible,
so instead of enforcing "normalized" internal values, we just reject
the attempted changes.
Fix #79664: PDOStatement::getColumnMeta fails on empty result set
As its name suggests, `sqlite3_data_count` returns the number of
columns in the current row of the result set; we are interested in the
number of columns regardless of the current row, so we have to use
`sqlite3_column_count` instead.
As of PHP 7.3.0, `sapi_cli_single_write()` is supposed to return `< 0`
on failure, but `fwrite()` returns a `size_t`, and signals error by
setting the stream's error indicator. We have to cater to that.
Nikita Popov [Thu, 28 May 2020 12:19:47 +0000 (14:19 +0200)]
Ensure Exception::getFile/getLine return type is correct
These return an untyped protected property, so we can't rely on
the type being correct.
Also add return types to the interface -- normally this would be
a no-go, but Throwable is a special interface that can only
be implemented internally, so we control all implementations.
Nikita Popov [Mon, 25 May 2020 10:10:41 +0000 (12:10 +0200)]
Convert Exception::getMessage() result to string
We specify that the return type of Exception::getMessage() is a
string. However, we don't currently ensure this, because
Exception::$message is a protected member that can be set to any
type. Fix this by performing an explicit type-cast.
This also requires a temporary refcount increment in the __toString()
object handler, because there is no additional owner of the object,
and it may get released prematurely as part of the __toString() call.
Dmitry Stogov [Thu, 28 May 2020 09:28:05 +0000 (12:28 +0300)]
Split "opcache.jit_max_recursion_unroll" into "opcache.jit_max_recursive_calls" and "opcache.jit_max_recursive_returns".
It's possible to disable recording of "recursive return loops" setting opcache.jit_max_recursive_returns to 0.
Tyson Andre [Wed, 29 Apr 2020 22:35:52 +0000 (18:35 -0400)]
[RFC] Always enable JSON support in php 8.0
Currently, it's possible to disable the json extension with
`./configure --disable-json` (for historical reasons that no longer apply).
However, JSON is widely used in many use cases - web sites, logging output,
and as a data format that can be used to share data with many applications
and programming languages,
so I'd personally find it useful if it was always enabled.
Examples of where this would be useful:
- For internal classes to be able to implement `JsonSerializable`
which currently requires a hard dependency on the JSON extension.
- For PHP users to publish single-file scripts that use json_encode and
json_decode and don't require polyfills or less readable var_export output.
(polyfills are less efficient and may have issues with recursive data
structures)
- So that php-src's own modules, tools and test cases can start using JSON
if it's a good choice for encoding a value. (same for PECLs)
https://wiki.php.net/rfc/jsond mentions that in PHP 5,
> The current Json Parser in the json extension does not have a free license
> which is a problem for many Linux distros.
> This has been referenced at Bug #63520.
> That results in not packaging json extension in the many Linux distributions.
Starting in php 7.0 with the switch to jsond,
It looks like licensing is no longer an issue.
Changes:
- Remove all flags related to JSON such as `configure --disable-json`
- Require that JSON be compiled statically instead of as a shared library
Examples of uses of JSON in various distros
(backwards incompatible changes such as changing packaging are typically
reserved for major versions, and 8.0 is a major version)
- JSON is required by `php-cli` or `php` in ubuntu:
https://packages.ubuntu.com/focal/php/
- The php-json package has to be installed separately
from the PHP binary in Fedora repos.
Apparently, breakpoints and watchpoints are practically disabled if
run with OPcache JIT under Windows, so we mark the affected tests as
xfail in that case for the time being.
If * is used for width/precision in printf, then the width/precision
is provided by a printf argument instead of being part of the format
string. Semantics generally match those of printf in C.
This can be used to easily reproduce PHP's float printing behavior:
// Locale-sensitive using precision ini setting.
// Used prior to PHP 8.0.
sprintf("%.*G", (int) ini_get('precision'), $float);
// Locale-insensitive using precision ini setting.
// Used since to PHP 8.0.
sprintf("%.*H", (int) ini_get('precision'), $float);
// Locale-insensitive using serialize_precision ini setting.
// Used in serialize(), json_encode() etc.
sprintf("%.*H", (int) ini_get('serialize_precision'), $float);