This was once part of TSRM but then got refactored into the windows
implementation win32/readdir.h directly. Instead of including such files
directly code should use zend_virtual_cwd.h which is already part of the
php.h file.
There is now only a single M4 macro in the legacy acinclude.m4 file. A
separate acinclude file was once used with a standalone Zend engine
building but with current build system this can be simplified a bit.
FOREACH_END_DEL() does not call the destructor by itself, we need to
explicitly call it. Due to the missing dtor call the functions were
not unregistered early, which resulted in later shutdown segfaults.
By introducing a hook that is called whenever one of
internal_encoding / input_encoding / output_encoding changes, so
that mbstring can adjust it's internal state.
This also makes internal_encoding work with zend multibyte.
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.
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.
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.
When a connection is closed, we also need to remove the hash entry
from the regular_list, as it now points to freed memory. To do this
store a reverse mapping from the connection to the hash string.
It would be nicer to introduce a wrapping structure for the pgsql
link resource that could store the hash (and notices), but that would
require large changes to the extension, so I'm going for a more
minimal fix here.
Nikita Popov