This solves [#79628](https://bugs.php.net/79628).
Similar to `ReflectionClass::getMethods()` and `ReflectionClass::getProperties()`,
this new `$filter` argument allows the filtering of constants defined in a class by
their visibility.
For that, we create three new constants for `ReflectionClassConstant`:
* `IS_PUBLIC`
* `IS_PROTECTED`
* `IS_PRIVATE`
Closes GH-5649.
This makes it always throw a TypeError, moreover this makes the
error message consistent.
Added a warning mentioning that the second parameter is now ignored
when passed false.
Closes GH-5301
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.
Closes GH-5495
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);
Closes GH-5432.
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.
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.
If opcache.record_warnings is enabled, opcache will record
compilation warnings and replay them when the file is included
again. The primary use case I have in mind for this is automated
testing of the opcache file cache.
This resolves bug #76535.
This deprecates:
ReflectionParameter::isArray()
ReflectionParameter::isCallable()
ReflectionParameter::getClass()
These APIs have been superseded by ReflectionParameter::getType()
since PHP 7.0. Types introduced since that time are not available
through the old APIs, and their behavior is getting increasingly
confusing. This is how they interact with PHP 8 union types:
* isArray() will return true if the type is array or ?array,
but not any other union type
* Same for isCallable().
* getClass() will return a class for T|int etc, as long as the
union only contains a single type. T1|T2 will return null.
This behavior is not particularly reasonable or useful, and will
get more confusing as new type system extensions are added.
Closes GH-5209.
Behavior is same as for (int) $resource, just under a clearer
name. Also type-safe, in that the parameter actually needs to
be a resource.
Closes GH-5427.
Treatment of locales in PHP is currently inconsistent: The LC_ALL
locale is set to "C", as is standard behavior on program startup.
The LC_CTYPE locale is set to "", which will inherit it from the
environment. However, the inherited LC_CTYPE locale will only be
used in some cases, while in other cases it is necessary to perform
an explicit setlocale() call in PHP first. This is the case for
the locale-sensitive handling in the PCRE extension.
Make things consistent by *never* inheriting any locales from the
environment. LC_ALL, including LC_CTYPE will be "C" on startup.
A locale can be set or inherited through an explicit setlocale()
call, at which point the behavior will be fully consistent and
predictable.
Closes GH-5488.
Currently, disabling a function only replaces the internal
function handler with one that throws a warning, and a few
places in the engine special-case such functions, such as
function_exists. This leaves us with a Schrödinger's function,
which both does not exist (function_exists returns false) and
does exist (you cannot define a function with the same name).
In particular, this prevents the implementation of robust
polyfills, as reported in https://bugs.php.net/bug.php?id=79382:
if (!function_exists('getallheaders')) {
function getallheaders(...) { ... }
}
If getallheaders() is a disabled function, this code will break.
This patch changes disable_functions to remove the functions from
the function table completely. For all intents and purposes, it
will look like the function does not exist.
This also renders two bits of PHP functionality obsolete and thus
deprecated:
* ReflectionFunction::isDisabled(), as it will no longer be
possible to construct the ReflectionFunction of a disabled
function in the first place.
* get_defined_functions() with $exclude_disabled=false, as
get_defined_functions() now never returns disabled functions.
Fixed bug #79382.
Closes GH-5473.
RFC: https://wiki.php.net/rfc/throw_expression
This has an open issue with temporaries that are live at the time
of the throw being leaked. Landing this now for easier testing and
will revert if we cannot resolve the issue.
Closes GH-5279.
Closes GH-5353. From now on, PHP will have reflection information
about default values of parameters of internal functions.
Co-authored-by: Nikita Popov <nikita.ppv@gmail.com>
This reverts commit bb43a3822e.
After thinking about this a bit more, this is now going to be
a complete solution for the "readonly properties" case, for example:
unset($foo->readOnly->bar);
should also be legal and
$foo->readOnly['bar'] = 42;
should also be legal if $foo->readOnly is not an array but an
ArrayAccess object.
I think it may be better to distinguish better on the BP_VAR flag
level. Reverting for now.
$a->b->c = 'd';
is now compiled the same way as
$b = $a->b;
$b->c = 'd';
That is, we perform a read fetch on $a->b, rather than a write
fetch.
This is possible, because PHP 8 removed auto-vivification support
for objects, so $a->b->c = 'd' may no longer modify $a->b proper
(i.e. not counting interior mutability of the object).
Closes GH-5250.
It is hard to impossible to work around iconv() implementations which
do not properly set errno according to POSIX. We therefore do no
longer allow to build against such iconv() implementations.
Co-Authored-By: Nikita Popov <nikita.ppv@googlemail.com>
Currently, when writing something like
class X {
use T1, T2 {
func as otherFunc;
}
function func() {}
}
where both T1::func() and T2::func() exist, we will simply assume
that func refers to T1::func(). This is surprising, and it doesn't
really make sense that this particular method gets picked.
This commit validates that non-absolute method references are
unambiguous, i.e. refer to exactly one method. If there is
ambiguity, it is required to write T1::func as otherFunc or
similar.
Closes GH-5232.
Provides the last PCRE error as a human-readable message, similar
to functionality existing in other extensions, such as
json_last_error_msg().
Closes GH-5185.
var_dump() is debugging functionality, so it should print
floating-point numbers accurately. We do this by switching
to serialize_precision, which (by default) will print with
as much precision as necessary to preserve the exact value
of the float.
This also affects debug_zval_dump().
Closes GH-5172.
As an exception, we allow "Type $foo = null" to occur before a
required parameter, because this pattern was used as a replacement
for nullable types in PHP versions older than 7.1.
Closes GH-5067.
While the `$command` passed to `proc_open()` had to be wrapped in
double-quotes manually, that was implicitly done for all other
program execution functions. This could easily introduce bugs and
even security issues when switching from one to another program
execution function.
Furthermore we ensure that the additional quotes are always
unwrapped regardless of what is passed as `$command` by passing
the `/s` flag to cmd.exe. As it was, `shell_exec('path with
spaces/program.exe')` did execute program.exe, but adding an
argument (`shell_exec('path with spaces/program.exe -h)`) failed
to execute program.exe, because cmd.exe stripped the additional
quotes.
While these changes obviously can cause BC breaks, we feel that in
the long run the benefits of having consistent behavior for all
program execution functions outweighs the drawbacks of potentially
breaking some code now.
In order of preference, the generated name will be:
new class extends ParentClass {};
// -> ParentClass@anonymous
new class implements FirstInterface, SecondInterface {};
// -> FirstInterface@anonymous
new class {};
// -> class@anonymous
This is intended to display a more useful class name in error messages
and stack traces, and thus make debugging easier.
Closes GH-5153.
RFC: https://wiki.php.net/rfc/static_return_type
The "static" type is represented as MAY_BE_STATIC, rather than
a class type like "self" and "parent", as it has special
resolution semantics, and cannot be cached in the runtime cache.
Closes GH-5062.
This helps to avoid unnecessary IS_REFERENCE checks.
This changes some notices "Only variables should be passed by reference" to exception "Cannot pass parameter %d by reference".
Also, for consistency, compile-time fatal error "Only variables can be passed by reference" was converted to exception "Cannot pass parameter %d by reference"
Any number of arguments can be replaced by a variadic one, so
long as the variadic argument is compatible (in the sense of
contravariance) with the subsumed arguments.
In particular this means that function(...$args) becomes a
near-universal signature: It is compatible with any function
signature that does not accept parameters by-reference.
This also fixes bug #70839, which describes a special case.
Closes GH-5059.
libcurl 7.29.0 has been released almost eight years ago, so this
version is supposed to be available practically everywhere. This bump
also allows us to get rid of quite some conditional code and tests
catering to very old libcurl versions.
In the php-src repository, the test runner is named run-tests.php, but
when it is copied to the tests packs, it is renamed to run-test.php.
This renaming does not make sense, and is actually somewhat confusing.
Although changing the name back to run-tests.php constitutes a BC
break, we think the benefit of having a single name outweights the
disadvantages in the long run.
While `imagesetinterpolation()` is available as of PHP 5.5.0,
there is no according getter function, so users would have to track the
current interpolation method manually.
To remedy this, we introduce `imagegetinterpolation()` as thin wrapper
for `gdImageGetInterpolationMethod()` (which has been introduced with
libgd 2.1.1), and use `im->interpolation_id` as fallback for older
libgd. Since our bundled libgd does not yet have this function, we add
it.
We also simplify the recently introduced bug79068.phpt, where it is
sufficient to check that the interpolation method has not been changed.
Both filters are equivalent, but FILTER_VALIDATE_BOOL uses our
canonical name for the type (the only one permitted in type
declarations for example), so the new name is preferred long
term.
The old name may be deprecated in the future, but no specific
timeline is planned.
That parameter is mostly useless in practise, and likely has been
directly ported from the underlying `gdImagePolygon()` and friends,
which require that parameter since the number of elements of the point
array would otherwise be unknown. Typical usages of `imagepolygon()`,
`imageopenpolygon()` and `imagefilledpolygon()` pass `count($points)/2`
or hard-code this value as literal. Since explicitly specifying this
parameter is annoying and error-prone, we offer the possibility to omit
it, in which case the `$points` array must have an even number of
elements, and the number of points is calculated as `count($points)/2`.
According to RFC: https://wiki.php.net/rfc/union_types_v2
The type representation now makes use of both the pointer payload
and the type mask at the same time. Additionall, zend_type_list is
introduced as a new kind of pointer payload, which is used to store
multiple class types. Each of the class types is a tagged pointer,
which may be either a class name or class entry. The latter is only
used for typed properties, while arguments/returns will instead use
cache slots. A type list can contain a mix of both names and CEs at
the same time, as not all classes may be resolvable.
One thing this is missing is support for union types in arginfo
and stubs, which I want to handle separately.
I've also dropped the special object code from the JIT implementation
for now -- I plan to add this back in a different form at a later time.
For now I did not want to include non-trivial JIT changes together
with large functional changes.
Another possible piece of follow-up work is to implement "iterable"
as an internal alias for "array|Traversable". I believe this will
eliminate quite a few special-cases that had to be implemented.
Closes GH-4838.
Fix folding for the new helper method.
Clarify comment in UPGRADING:
The performance on associative arrays would also improve,
as long as no offsets were unset (no gaps).
Packed arrays can have gaps.
Closes GH-4873.
[ci skip]
If the offset is 100000, and there are no gaps in the packed/unpacked array,
then advance the pointer once by 100000,
instead of looping and skipping 100000 times.
Add a new test of array_slice handling unset offsets.
Closes GH-4860.
Add deprecated _ZendTestClass::__toString() method to preserve
an existing test.
ReflectionType::__toString() will now return a complete
representation of the type, as it should have originally. Users
that relied on nullability being absent should have been pushed
to ReflectionNamedType::getName() by the deprecation of
ReflectionType::__toString() in PHP 7.1 / PHP 7.4.
The fdiv() function is part of the fmod() / intdiv() family. It
implements a floating-point division with IEEE-754 semantics.
That is, division by zero is considered well-defined and does not
trigger any kind of diagnostic. Instead one of INF, -INF or NAN
will be returned, depending on the case.
This is in preparation for throwing DivisionByZeroError from the
standard division operator.
This removes object auto-vivification support.
This also means that we can remove the corresponding special
handling for typed properites: We no longer need to check that a
property is convertible to stdClass if such a conversion might
take place indirectly due to a nested property write.
Additionally OBJ_W style operations now no longer modify the
object operand, and as such we no longer need to treat op1 as a
def in SSA form.
The next step would be to actually compile the whole LHS of OBJ_W
operations in R rather than W mode, but that causes issues with
SimpleXML, whose object handlers depend on the current compilation
structure.
Part of https://wiki.php.net/rfc/engine_warnings.
While we generally prefer objects over resources for quite a while, the
procedural XMLWriter API still uses resources, although there is
already an object-oriented API which uses objects. This dichotomy
makes no sense, slightly complicates the implementation, and doesn't
allow a stepwise migration to the object-oriented API, which might be
desired. Thus we completely drop the XMLWriter resources in favor of
XMLWriter objects.
We consider the minor BC break acceptable for a major version, since
only explicit type checks (`is_resource()`, `gettype()` etc.) need to
be adapted.
The AI_IDN_ALLOW_UNASSIGNED and AI_IDN_USE_STD3_ASCII_RULES have
been deprecated by glibcs, and PHP 7.4 follows this deprecation.
This removes the offending flags for PHP 8.0.
Due to former restrictions of the libcurl API, curl multipart/formdata
file uploads supported only proper files. However, as of curl 7.56.0
the new `curl_mime_*()` API is available (and already supported by
PHP[1]), which allows us to support arbitrary *seekable* streams, which
is generally desirable, and particularly resolves issues with the
transparent Unicode and long part support on Windows (see bug #77711).
Note that older curl versions are still supported, but CURLFile is
still restricted to proper files in this case.
[1] <http://git.php.net/?p=php-src.git;a=commit;h=a83b68ba56714bfa06737a61af795460caa4a105>
Arbitrary DateInterval objects don't have well-defined comparison
semantics. Throw a warning and treat the objects as uncomparable.
Support for comparing DateInterval objects returned by
DateTime::diff() may be added in the future.
Use an XmlParser object instead of a resource. This is an internal
representation change, not a conversion to OO APIs. XmlParser objects
cannot be explicitly constructed, they are created through the usual
xml_parser_* APIs.
This change allows us to provide a proper get_gc() implementation,
thus resolving bugs #72793 and #76874.
xml_parser_free() is a no-op now and need not be called anymore.
php_filter_int (called via the constant FILTER_VALIDATE_INT) has the options min_range
and max_range. they allow the user to not only test if a value is a double but also if
the value is inside a specific range. php_filter_float (called via the constant
FILTER_VALIDATE_FLOAT) didn't provide this yet, making validation of numeric but
not-only-int values more complicated for the user.
this commits implements the options min_range and max_range for the function
php_filter_float to fix this inconsistency.
We currently have a large performance problem when implementing lexers
working on UTF-8 strings in PHP. This kind of code tends to perform a
large number of matches at different offsets on a single string. This
is generally fast. However, if /u mode is used, the full string will
be UTF-8 validated on each match. This results in quadratic runtime.
This patch fixes the issue by adding a IS_STR_VALID_UTF8 flag, which
is set when we have determined that the string is valid UTF8 and
further validation is skipped.
A limitation of this approach is that we can't set the flag for interned
strings. I think this is not a problem for this use-case which will
generally work on dynamic data. If we want to use this flag for other
purposes as well (mbstring?) then it might be worthwhile to UTF-8 validate
strings during interning. But right now this doesn't seem useful.
This variant of crc32 is heavily used by storage systems, such as iSCSI, SCTP,
Btrfs, ext4, and is increasingly being used in API (such as Google Cloud
Storage, and Apache Kafka).
This reverts commit a9e6667817.
Breakage found in the wild: Mockery uses a parent:: call in the
implementation regardless of whether the class has a parent or not:
4324afeaf9/library/Mockery/Mock.php (L600)
This change is not worth the compat break in 7.4.
This code is not compatible with PHP 7.0. The fact that nobody
complained that the mysqli embedded server functionality doesn't
build anymore seems like a strong signal that we can drop it...
Do not include unbound anonymous classes in get_declared_classes().
Note that earlier PHP versions would include the anonymous class in
get_declared_classes(), and return false until the class was bound,
but would not crash.
As of PHP 7.3.0, case-insensitive constants are deprecated. We catch
up on this with regard to ext/com_dotnet, which allows to import
constants from typelibs, by triggering a deprecation notice whenever
`com_load_typelib()` is called with `$case_sensitive` being `false`,
and whenever `com.autoregister_casesensitive` is set to `false`,
regardless of whether there are actually constants in the typelib which
would be imported.
SO_USER_COOKIE primarly to be traced via dtrace instrumentation.
If SO_USER_COOKIE is available, the rest is so the former is
two years old while the rest is from around 2008.
I'm removing the argument entirely here, but we might want to change
this to passing null or and empty array instead, if the impact of
dropping it entirely turns out to be too large.
This was deprecated as part of https://wiki.php.net/rfc/deprecations_php_7_2
as a doc-only deprecation.
I'm counting this towards the non-string needle deprecation from
https://wiki.php.net/rfc/deprecations_php_7_3. I wasn't aware that
mb_ereg_replace() is also affected by this issue. It's even more
ridiculous than usual here, because the integer is interpreted as
an ASCII codepoint, even though these are supposed to be multibyte
functions :(
Access to undefined constants will now always result in an Error
exception being thrown.
This required quite a few test changes, because there were many
buggy tests that unintentionally used bareword fallback in combination
with error suppression.
There are probably some improvements we can do to the SPL
implementation now that __autoload() is gone. In particular having
EG(autoload_func) as a property zend function, rather than a simple
callback probably doesn't make sense.
This is part of https://wiki.php.net/rfc/case_insensitive_constant_deprecation.
This commit only removes the ability to declare such constants from
userland. Before the functionality can be removed entirely, it's
necessary to figure out the handling of true/false/null first.
RFC: https://wiki.php.net/rfc/null_coalesce_equal_operator
$a ??= $b is $a ?? ($a = $b), with the difference that $a is only
evaluated once, to the degree that this is possible. In particular
in $a[foo()] ?? $b function foo() is only ever called once.
However, the variable access themselves will be reevaluated.
Formerly, a single option `--with-gd` was sufficient to enable the
extension, and to determine whether to use the system or the bundled
libgd depending on whether a directory was passed. Since pkg-config
determines the path automatically, we now offer `--enable-gd` (whether
the extension should be build) and `--with-external-gd` (whether to use
the system libgd).
RFC: https://wiki.php.net/rfc/typed_properties_v2
This is a squash of PR #3734, which is a squash of PR #3313.
Co-authored-by: Bob Weinand <bobwei9@hotmail.com>
Co-authored-by: Joe Watkins <krakjoe@php.net>
Co-authored-by: Dmitry Stogov <dmitry@zend.com>
We already detect the case where we're entirely outside a class --
now also check whether there actually is a parent.
This is a minor BC break, in that code that was never executed
might have previously contained an invalid parent:: reference without
generating an error.
Albeit CSV is still a widespread data exchange format, it has never been
officially standardized. There exists, however, the “informational” RFC
4180[1] which has no notion of escape characters, but rather defines
`escaped` as strings enclosed in double-quotes where contained
double-quotes have to be doubled. While this concept is supported by
PHP's implementation (`$enclosure`), the `$escape` sometimes interferes,
so that `fgetcsv()` is unable to correctly parse externally generated
CSV, and `fputcsv()` is sometimes generating non-compliant CSV. Since
PHP's `$escape` concept is availble for many years, we cannot drop it
for BC reasons (even though many consider it as bug). Instead we allow
to pass an empty string as `$escape` parameter to the respective
functions, which results in ignoring/omitting any escaping, and as such
is more inline with RFC 4180. It is noteworthy that this is almost no
userland BC break, since formerly most functions did not accept an empty
string, and failed in this case. The only exception was `str_getcsv()`
which did accept an empty string, and used a backslash as escape
character then (which appears to be unintended behavior, anyway).
The changed functions are `fputcsv()`, `fgetcsv()` and `str_getcsv()`,
and also the `::setCsvControl()`, `::getCsvControl()`, `::fputcsv()`,
and `::fgetcsv()` methods of `SplFileObject`.
The implementation also changes the type of the escape parameter of the
PHP_APIs `php_fgetcsv()` and `php_fputcsv()` from `char` to `int`, where
`PHP_CSV_NO_ESCAPE` means to ignore/omit escaping. The parameter
accepts the same values as `isalpha()` and friends, i.e. “the value of
which shall be representable as an `unsigned char` or shall equal the
value of the macro `EOF`. If the argument has any other value, the
behavior is undefined.” This is a subtle BC break, since the character
`chr(128)` has the value `-1` if `char` is signed, and so likely would
be confused with `EOF` when converted to `int`. We consider this BC
break to be acceptable, since it's rather unlikely that anybody uses
`chr(128)` as escape character, and it easily can be fixed by casting
all `escape` arguments to `unsigned char`.
This patch implements the feature requests 38301[2] and 51496[3].
[1] <https://tools.ietf.org/html/rfc4180>
[2] <https://bugs.php.net/bug.php?id=38301>
[3] <https://bugs.php.net/bug.php?id=51496>
The `$mode` parameter of `imagecropauto()` defaults to `-1`. However,
`-1` is changed to `GD_CROP_DEFAULT` right away, so basically the
default is `GD_CROP_DEFAULT`, which is rather confusing and
unnecessary.
Therefore, we change the default to `IMG_CROP_DEFAULT`, but still allow
an explicit `-1` to be passed for BC reasons, in which case we trigger
a deprecation notice, so we can rid the `-1` support eventually.
`GD_CROP_DEFAULT` and `GD_CROP_SIDES` are names of libgd constants, and
as such they are not relevant for userland developers. Therefore, we
replace them by the constant names of our wrapper, i.e.
`IMG_CROP_DEFAULT` and `IMG_CROP_SIDES`, respectively.
Since upstream does not appear to move in any way[1], we sync our
behavior. Even though the BC break is ugly (which is the reason we
target master only), having to deal with different algorithms is even
worse for portable userland code.
[1] <https://github.com/libgd/libgd/issues/334>
Since cropping support has been added to our bundled libgd,
`gdImageAutoCrop` differs from upstream in that `GD_CROP_DEFAULT` falls
back on `GD_CROP_SIDES` if there is no transparent color in the image.
While this difference seem to be a useful improvement in our bundled
libgd, upstream has not yet signaled that there willing to back-port
it[1], so we revert it to stay in sync with upstream.
We also remove the additional NULL bailout at the end of the function,
which doesn't appear to be relevant any longer since bug 77198 has been
fixed.
[1] <https://github.com/libgd/libgd/issues/298>
`SQLite3::readOnly()` uses `sqlite3_stmt_readonly()` which is only
available as of libsqlite 3.7.4. For older SQLite3 versions we return
always `false`, which can be confusing. Instead of sticking with this
behavior, or even undefining the method for old SQLite3 versions, we
lift the requirements to SQLite 3.7.4 (released on 2010-12-08),
according to a respective discussion[1].
Since pdo_sqlite doesn't use `sqlite3_stmt_readonly()`, we stick with
the minimum requirement of SQLite 3.5.0.
[1] <https://github.com/php/php-src/pull/3614>
Serializing `SQLite3`, `SQLite3Stmt` and `SQLite3Result` instances is
possible but pointless, since unserializing results in uninitialized
instances, which will bail out of any method call. Therefore, we deny
serialization and unserialization in the first place.
Besides the common `:param` notation to designate named parameters in
prepared statements, SQLite3 also supports `@param` and `$param`.
While the latter is mostly to support the Tcl programming language, and
would be confusing for PHP's sqlite3 binding due to the similarity with
string interpolation, the former is common under .NET and raises no
such issue. Therefore we add support for it.
This patch has been developed in cooperation with @BohwaZ.
It is possible to pass flags when opening an SQLite database. For
Sqlite < 3.5.0 these are ignored, since `sqlite3_open` doesn't support
flags. Neither a warning or notice is raised in this case, nor is this
behavior documented in the PHP manual. Instead of fixing it either
way, we lift the requirement to SQLite 3.5.0 (released on 2007-09-04)
instead of the former SQLite 3.3.9 (released on 2007-01-04).
Static calls to non-static methods have been fully deprecated in
PHP 7.0 as part of https://wiki.php.net/rfc/reclassify_e_strict.
A combination of ReflectionMethod::getClosure() ("fake closures")
and Closure::bindTo() etc can be used to achieve the same behavior.
This commit ensures that a deprecation notice will be thrown also
in this case.
