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 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 :(
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.
