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);
Máté Kocsis [Mon, 25 May 2020 17:28:15 +0000 (19:28 +0200)]
Improve type error messages when an object is given
From now on, we always display the given object's type instead of just reporting "object".
Additionally, make the format of return type errors match the format of argument errors.
* PHP-7.4:
Enable phpdbg tests on AppVeyor
Make phpdbg test portable
Fix several mostly Windows related phpdbg bugs
Fix #73926: phpdbg will not accept input on restart execution
* Deactivate potentially remaining watchpoints after REPL
Otherwise the memory could still be protected, resulting in segfaults
during shutdown.
* NULL zend_handlers_table after freeing
As of commit 4130fe4[1], the `zend_handlers_table` is explicitly
freed in the `zend_vm_dtor()`. Since phpdbg (and maybe some other
SAPIs) may restart the engine afterwards, we have to make sure that
the table is also NULLed.
* Only set context option if there is a context
In other words, we must not follow the null pointer.
* Cater to file handles without attached console
File handles do not necessarily have an attached console (for
instance, pipes do not), in which case `GetConsoleScreenBufferInfo()`
fails. In this case we set a default value (`40`) for lines like on
other systems.
On startup, PHP deliberately changes the floating point control word to
enforce binary64 format for the calculations for best consistency
across platforms. However, this is unnessary for x86_64 architectures,
because in this case SSE instructions are used by default, and there is
no good reason to pass `-mfpmath=i387` or such.
Therefore, we can skip the modification, which has the benefit that
system libraries are free to work in the mode of their liking.
Nikita Popov [Tue, 26 May 2020 12:59:40 +0000 (14:59 +0200)]
Respect typed references in catch assignment
I decided to null out EG(exception) early here, which means only
the exception from the dtor / ref assign is preserved, and the
previous exception is not chained in. This is more robust, and
I don't think this situation is common enough to be bothered about
the precise behavior.
Nikita Popov [Tue, 26 May 2020 12:06:36 +0000 (14:06 +0200)]
Fix zend_assign_to_typed_ref() implementation
There was some confusion going on here regarding the original
value vs the copied value.
I've dropped the needs_copy variable, because this code is not
inlined, so it would always be true anyway.
What we need to do is perform a move-assignment of the copied
value (in which case we don't care about performing the assignment
before destroying garbage), and destroying the original value
for the VAR/TMP cases. This is a bit complicated by the fact that
references are passed in via a separate ref variable, so we can't
just ptr_dtor the original variable.
Even if that header file is available, we better consider it private,
and don't include it. The information about whether SSL support is
enabled is now missing (`USE_(OPEN)SSL`), and it seems there is no
alternative way to get it (`PQinitSSL()` is always defined), so we
remove it from the PHP info. Furthermore, the `PG_VERSION` and
`PG_VERSION_STR` macros are no longer available, but as of libpq 9.1
there is `PQlibVersion()` which allows us to construct `PG_VERSION` in
a most likely backwards compatible manner. The additional information
available through `PG_VERSION_STR` is lost, though, so we define
`PGSQL_LIBPQ_VERSION_STR` basically as alias of `PGSQL_LIBPQ_VERSION`,
and deprecate it right away.
Since we are now requiring at least libpq 9.1, we can remove some
further compatibility code and additional checks.
Regarding the raised requirements: official support for PostGreSQL 9.0
ended on 2015-10-08, and even CentOS 7 already has PostGreSQL 9.2, so
this is not supposed to be too much of an issue.
Tyson Andre [Fri, 22 May 2020 21:36:32 +0000 (17:36 -0400)]
Fail in `./configure` when no opcache shm backends exist
This can be seen when the `./configure` step fails to detect `HAVE_SHM_*`,
e.g. due to missing a necessary dependency to compile the test scripts.
(Run `./configure`, run `yum install libtool-ltdl-devel` for missing dependencies,
then run `make`, and php can end up built with 0 shared memory opcache caches)
Give a clearer error message than `unknown`
Searching for `opcache "Fatal Error Unable to allocate shared memory segment of"
"unknown: No such file or directory"` reveals issues such as
https://github.com/termux/termux-packages/issues/2234
We can safely assume that users have at the very least libpq 7.4, for
which official support ended on 2010-10-01; even CentOS 6 has 8.4 now.
It is also noteworthy that PDO_PGSQL already requires libpq 7.4 or
later.
On startup, PHP deliberately changes the floating point control word to
enforce binary64 format for the calculations for best consistency
across platforms. However, this is unnessary when compiling under
`__SSE__`, because in this case the x87 instructions are not used.
Therefore, we can skip the modification, which has the benefit that
system libraries are free to work in the mode of their liking.
Fix #79615: Wrong GIF header written in GD GIFEncode
The color resolution is expected in bits 4-6 of the packed fields byte
of the logical screen descriptor (byte 10 of the GIF data stream),
according to the specification[1], section 18.
projects / php / log