atoi()'s return value is actually undefined when an underflow or
overflow occurs. For example on 32-bit on my system the overflow test
which inputs "h2147483648" results in repetitions==2147483647 and on
64-bit this gives repetitions==-2147483648. The reason the test works on
32-bit is because there's a second undefined behaviour problem:
in case 'h' when repetitions==2147483647, we add 1 and divide by 2.
This is signed-wrap undefined behaviour and accidentally triggers the
overflow check like we wanted to.
Avoid all this trouble and use strtol with explicit error checking.
This also fixes a semantic bug where repetitions==INT_MAX would result
in the overflow check to trigger, even though there is no overflow.
Closes GH-10943.
The condition `code == 0x0450 || code == 0x045D` is always false because
of an incorrect range check on code.
According to the BMP coverage in the encoding spec for ISO-8859-5
(https://encoding.spec.whatwg.org/iso-8859-5-bmp.html) the range of
valid characters is 0x0401 - 0x045F (except for 0x040D, 0x0450, 0x045D).
The current check has an upper bound of 0x044F instead of 0x045F.
Fix this by changing the upper bound.
Closes GH-10399
Signed-off-by: George Peter Banyard <girgias@php.net>
The check that was supposed to check whether the array slot was UNDEF
was wrong and never triggered. This resulted in a replacement with the
empty string or the wrong string instead of the correct one. The correct
check pattern can be observed higher up in the function's code.
Closes GH-10323
Signed-off-by: George Peter Banyard <girgias@php.net>
Change error message of sprintf/printf for missing/invalid position
specifier to make it clear that this is talking about the specifier,
not the number of arguments passed to the function. Also mention
the upper limit of INT_MAX.
Closes GH-7515.
The deprecation message was originally introduced in 3e6b447 (#6494).
I first encountered this notice when testing the MongoDB extension
with PHP 8.1, which produced many duplicate messages that provided
no detail about the particular class that needed to be fixed.
Closes GH-7346.
This used to be necessary in the past because the NUM_BUF_SIZE
was set to 512, which is shorter than DOUBLE_MAX_LENGTH. Now the
value is either DOUBLE_MAX_LENGTH or larger (2048).
Adding two `zend_long`s may overflow, and casting `size_t` to
`zend_long` may truncate; we can avoid this here by enforcing unsigned
arithmetic.
Closes GH-7240.
These are deprecated in favor of date()/DateTime::format() (for
locale-indendent formatting) and IntlDateFormatter::format()
(for locale-dependent formatting).
Part of https://wiki.php.net/rfc/deprecations_php_8_1.
Updates the deprecation message for implicit incompatible float to int conversion from:
```
Implicit conversion from non-compatible float %.*H to int in %s on line %d
```
to
```
Implicit conversion from float %.*H to int loses precision in %s on line %d
```
Related: #6661
This format matches against null bytes, and prevents the test
expectation from being interpreted as binary data.
bless_tests.php will automatically replace \0 with %0 as well.
Create name using either zend_init_string_fast (no repetitions) or by concatenating the name with zend_print_ulong_to_buf. This is much more efficient than using snprintf. We also avoid repeated strlen() calculations.
This is a re-application of the original match against master.
The patch was originally applied to master, then reverted from
there, incorrectly applied to PHP-8.0, reverted from there due
to ABI break, and now lands on master again. We can only hope
that it does not get reverted again ;)
If Serializable is implemented, require that __serialize() and
__unserialize() are implemented as well, else issue a deprecation
warning.
Also deprecate use of PDO::FETCH_SERIALIZE.
RFC: https://wiki.php.net/rfc/phase_out_serializable
Closes GH-6494.
This deprecates passing null to non-nullable scale arguments of
internal functions, with the eventual goal of making the behavior
consistent with userland functions, where null is never accepted
for non-nullable arguments.
This change is expected to cause quite a lot of fallout. In most
cases, calling code should be adjusted to avoid passing null. In
some cases, PHP should be adjusted to make some function arguments
nullable. I have already fixed a number of functions before landing
this, but feel free to file a bug if you encounter a function that
doesn't accept null, but probably should. (The rule of thumb for
this to be applicable is that the function must have special behavior
for 0 or "", which is distinct from the natural behavior of the
parameter.)
RFC: https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg
Closes GH-6475.
That bug report originally was about `parse_url()` misbehaving, but the
security aspect was actually only regarding `FILTER_VALIDATE_URL`.
Since the changes to `parse_url_ex()` apparently affect userland code
which is relying on the sloppy URL parsing[1], this alternative
restores the old parsing behavior, but ensures that the userinfo is
checked for correctness for `FILTER_VALIDATE_URL`.
[1] <https://github.com/php/php-src/commit/5174de7cd33c3d4fa591c9c93859ff9989b07e8c#commitcomment-45967652>
To avoid that `parse_url()` returns an erroneous host, which would be
valid for `FILTER_VALIDATE_URL`, we make sure that only userinfo which
is valid according to RFC 3986 is treated as such.
For consistency with the existing url parsing code, we use ctype
functions, although that is not necessarily correct.
To avoid that `parse_url()` returns an erroneous host, which would be
valid for `FILTER_VALIDATE_URL`, we make sure that only userinfo which
is valid according to RFC 3986 is treated as such.
For consistency with the existing url parsing code, we use ctype
functions, although that is not necessarily correct.
To avoid that `parse_url()` returns an erroneous host, which would be
valid for `FILTER_VALIDATE_URL`, we make sure that only userinfo which
is valid according to RFC 3986 is treated as such.
For consistency with the existing url parsing code, we use ctype
functions, although that is not necessarily correct.
Make strspn($str1, $str2, $offset, $length) behaviorally
equivalent to strspn(substr($str1, $offset, $length), $str2)
by not throwing for out of bounds offset.
There have been two reports that this change cause issues,
including bug #80285.
Kamil Tekiela