HT_FLAGS() includes the full flag word, including the iterator
count. When we're fully reassigning it, we need to make sure that
we either really do want to copy the iterator count (as in some
cases in array.c) or we need to mask only the actual flag byte.
Add an assert to hash_iterators_del() to make sure the iterator
count is non-zero (which is how I ran into this) and make sure that
the iterator count is correctly preserved during array splicing.
When a HT iterator is one past the end and we rehash, we need to make
sure that it is move to the new one past the end position, to make
sure that newly inserted elements are picked up.
In the hash position APIs, make sure we always advance to the next
non-undef element and not just when the position is 0 (similar to
what foreach does). This can happen when the position of an
ArrayIterator is one past its current end and a new element is
inserted not directly at that position because the array is packed.
There is still a bug here (as shown in the tests), but this is a
separate issue that also affects plain array iteration in foreach.
Merge branch 'PHP-7.4' of git.php.net:php-src into PHP-7.4
* 'PHP-7.4' of git.php.net:php-src:
Remove not needed extension generated files gitignores
Add test for curl_version()
Fixed bug #77895
Zero sockaddr struct
Fix saproxy_property_write signature
Correctly destroy reference in ArrayObject sort
After fixing comparison operator typos in f73c104927b64d6137cbe42bf42260d9349cbd02 this test is failing. I
believe the comparison here should be using < rather than ==.
It seems like GCC 5 likes to warn about exactly those trivial strict
aliasing violations that it's not going to miscompile anyway and the
warnings are gone in newer versions. Just disable the noise.
and appends them to the generated config.h.in files. With AC_INIT change
via afd52f9d9986d92dd0c63832a07ab1a16bf11d53 where package version, URL,
bug report location and similar meta data are defined, these
preprocessor macros are then non empty strings in the generated
configuration header file. When using phpize, PHP shares the config
files in extensions, warnings of redefined macros appear, such as:
- `warning: 'PACKAGE_NAME' macro redefined`
This patch now disables these non utilized symbols in the generated
config header files.
Better practice would be to include only API specific headers where
needed but this would require even more refactorings. Some extensions
such as pcre, pgsql, and pdo_pgsql solve this issue by undefining some
of these symbols before including the library configuration headers in
the code also. Because these symbols can be defined by any library which
uses Autotools.
Additionally, the unused PACKAGE_* symbols were cleaned for the bundled
libmbfl library and with this patch not needed undef code removed.
This is unnecessary convoluted... we just want to find the position
of the dot. Using php_strtok_r requires a copy of the string, and the
implementation also relied on the specific semantics of the scratch
space that strtok_r uses.
This one looks semi-legit, in case php_stream_eof() returns false
but php_stream_get_line() fails. Not totally sure this cannot
happen, so rewriting to check both conditions at once.
And fix incorrect variable shadowing in add_config_entry(). However,
the test doesn't hit this case, as it requires a nested array. I'm
not sure if it's possible to produce nested arrays from ini?
This code was reusing the _bailout variable from
SOAP_CLIENT_BEGIN/END_CODE(). As _bailout is not volatile, modifying
it after the setjmp call and then reading it back on return is
illegal. Use a separate local bailout variable instead.
This fixes the miscompile introduced by marking zend_bailout() as
noreturn.
As we are breaking out of the for loop setting i = ssa_vars_count
doesn't do anything, but it confuses GCC into throwing a no-overflow
assumption warning.
If there are no warnings, we may end up compiling more than 10
minutes without output, in which case the build times out. Use
travis_wait to avoid this.
readdir_r() is deprecated in modern glibc versions. readdir() is
thread safe in practice, as long as there are no concurrent accesses
on the *same* directory stream.
This is only relevant for the gcrypt backend, which is no longer in
use. I couldn't find any hard info on when exactly gcrypt support was
dropped, but nette is the default since 2.11.1. Most code that still
has the gcrypt handling is checking against < 2.12. In either case,
those versions were released in 2010/2011.
We're not using this anywhere, and it causes warnings, so I'm
dropping it. If we do end up needing this, it should be reintroduced
with a ZEND_ prefix.
projects / php / log