This reverts commit 2fba646837.
PCRE-8.39 throws weird valgrind backtraces on some systems, see
http://news.php.net/php.cvs/93494 . Those could be false positives
due to some changes in JIT, still i couldn't 100% ensure this.
Thus, better we continue to ship 8.38 bundled for now, and apply
patches, if needed.
This reverts commit 14d674442e.
I misread the discussion on the bug -- this is not the correct
fix. However the other proposed fix does not work either, so just
reverting for now.
Fixes bugs #61967, #62607, #69068, #70713.
The primary changes are:
a) Use the ht_iterator mechanism to ensure safety not only if the
iterated array itself changes, but also if it is replaced (and
potentially destroyed) entirely. We use the same semantics for
behavior under modification as foreach-by-reference. In
particular, we advance to the next element before processing it.
If the iterated entity is exchanged we iterate the new one from
the start. If it is not an array/object we warn and abort.
b) Always create a reference to the current value. Previously the
code kept the value as a non-reference and updated it to the
reference value produced by the user callback. However this is
unsafe, as the array may have been reallocated in the meantime,
so the previous value pointer is no longer value.
c) Around a recursive walk, incref the reference containing the
array. This ensures that the location where the currently
iterated value is stored cannot be freed.
One problem I was not able to solve is that we cannot decrement
the apply count if the array is exchanged during a recursive walk.
Julian days < 347998 denote invalid Jewish calendar dates, so
cal_from_jd($jd, CAL_JEWISH) and jdmonthname($jd, CAL_MONTH_JEWISH) should
actually fail. For BC we don't yet let them though, but we fix the OOB read
that happens in this case, and we also adjust cal_from_jd()'s return value
to have empty strings for "abbrevdayname" and "dayname" instead of "Sun"/
"Sunday" and NULL for "dow" instead of 0, which doesn't make any sense.
