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).
