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
PDO implement half of this, but this functionality is generally
useful. Provide these as zend_u64_to_str and zend_i64_to_str to
complement zend_long_to_str.
This PR corrects misspellings identified by the check-spelling action.
The misspellings have been reported at jsoref@b6ba3e2#commitcomment-48946465
The action reports that the changes in this PR would make it happy: jsoref@602417c
Closes GH-6822.
Otherwise we may have inconsistent refcounts after OOM.
I expect this problem is much more prevalent, but this at least
fixes some string/array separation cases.
Fixes oss-fuzz #30999.
We're starting to see a mix between uses of zend_bool and bool.
Replace all usages with the standard bool type everywhere.
Of course, zend_bool is retained as an alias.
This function is unused in php-src, and has somewhat dubious
semantics, especially since we switched convert_to_long to not
use strtol for the base 10 case.
If you want to convert strings from a different base, use
ZEND_STRTOL directly.
This function is unused, and also not particularly useful now that
PHP no longer prints doubles in a locale-sensitive way unless
someone really goes out of their way to force it.
Voidification of Zend API which always succeeded
Use bool argument types instead of int for boolean arguments
Use bool return type for functions which return true/false (1/0)
Use zend_result return type for functions which return SUCCESS/FAILURE as they don't follow normal boolean semantics
Closes GH-6002
RFC: https://wiki.php.net/rfc/saner-numeric-strings
This removes the -1 allow_error mode from is_numeric_string functions and replaces it by
a trailing boolean out argument to preserve BC in a couple of places.
Most of the changes can be resumed to "numeric" strings which emitted a E_NOTICE now emit
a E_WARNING and "numeric" strings which emitted a E_WARNING now throw a TypeError.
This mostly affects:
- String offsets
- Arithmetic operations
- Bitwise operations
Closes GH-5762
Add ZVAL_CHAR/RETVAL_CHAR/RETURN_CHAR as a shortcut for using
ZVAL_INTERNED_STRING and ZSTR_CHAR.
Add zend_string_init_fast() as a helper for the empty string /
one char interned string / zend_string_init() pattern.
Also add corresponding ZVAL_STRINGL_FAST etc macros.
Closes GH-5684.
Instead of looping, use straight-line code with the following
layout:
1. Try to apply the base operation on the dereferenced operands.
2. Try overloaded object operations.
3. Try to convert operands to number, else error out.
4. Apply the base operation on the converted operands.
This makes the code easier to reason about and fixes some edge-case
bugs:
1. We should only try invoking operator overloading once prior to
type conversion. Previously it was invoked both before and after
type conversion.
2. We should not modify any values if an exception is thrown.
Previously we sometimes modified the LHS of a compound assignment
operator.
3. If conversion of the first operand fails, we no longer try to
convert the second operand. I think the previous behavior here
was fine as well, but this still seems a more typical.
This will also make some followup changes I have in mind simpler.
Avoid subtle differences in behavior depending on whether the
handler is absent or returns FAILURE.
If you previously set cast_object to NULL, create a handler that
always returns FAILURE instead.
Make cast_object return FAILURE for casts to int/float, rather than
throwing a notice and returning SUCCESS. Instead move the emission
of the notice to the code invoking cast_object. This will allow us
to customize the behavior per call-site.
This change is written to be NFC, and the code in
zend_std_compare_objects() should illustrate the current behavior
doesn't make a lot of sense.
