Unfortunately, libedit is locale based and does not accept UTF-8
input when the C locale is used. This patch switches the default
locale to C.UTF-8 instead (if it is available). This makes libedit
work and I believe it shouldn't affect behavior of single-byte
locale-dependent functions that PHP otherwise uses.
Closes GH-7635.
zend_class_implements_interface works fine if the "class" is an
interface, so simply drop this assertion. This avoids the need to
special case this situation.
Add a family of upper case conversion functions to zend_operators.c,
by analogy with the lower case functions.
Move the single-character conversion macros to the header so that they
can be used as a locale-independent replacement for tolower() and
toupper().
Factor out the ugly bits of the SSE2 case conversion so that the four
functions that use it are easy to read and processor-independent.
Use the new ASCII upper case functions in ext/xml, ext/pdo_dblib and as
an optimization for strtoupper() when the locale is "C".
These are thin wrappers ... around the wrong functions. They call
the "_l()" version of the underlying APIs. For clarify, just call
the wrapped API directly.
zend_double_to_str() converts a double to string in the way that
(string) would (using %.*H using precision).
smart_str_append_double() provides some more fine control over
the precision, and whether a zero fraction should be appeneded
for whole numbers.
A caveat here is that raw calls to zend_gcvt and going through
s*printf has slightly different behavior for the degenarate
precision=0 case. zend_gcvt will add a dummy E+0 in that case,
while s*printf convert this to precision=1 and will not. I'm
going with the s*printf behavior here, which is more common,
but does result in a minor change to the precision.phpt test.
Trying to allocate a `zend_string` with a length only slighty smaller
than `SIZE_MAX` causes an integer overflow, so callers may need to
check that explicitly. To make that easy in a portable way, we
introduce `ZSTR_MAX_LEN`.
Closes GH-7294.
It's the same as (int) zend_atol() -- it doesn't try to do anything
integer size specific. Canonicalize to one function in preparation
for renaming zend_atol() to something less misleading.
FFI test is adjusted to use a zend_test function. It just calls
zend_atol() internally, but could really be anything.
Co-authored-by: Christoph M. Becker <cmbecker69@gmx.de>
We can't destroy the result operand early, because the division
might fail, in which case we need to preserve the original value.
Place the division result in a temporary zval, and only copy it
on success.
Fixes oss-fuzz #35876.
The result == op1 check did not work properly here, because op1
was &op1_copy at this point. Move the division by zero reporting
out of the _base function, so it can check the original op1.
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.
