Actually, there is no negative zero at all. We obey Postel's law, and
still accept negative zeroes, but we store them as positive zeroes
after the conversion from string, i.e. we normalize before further
processing.
The behavior of date parsing has changed and is reflected in the
changelog. Invalid dates are not accepted, in particular dates with a
negative year, as in this test.
bug75178.phpt fails on Windows, because the stderr output is not
interspersed with stdout output there, but rather is appended to the
end. The fix is analogous to bug72093.phpt.
Since `bcpowmod()` does not support non-integral operands, we have to
truncate these in addition to emitting a respective warning. We also
have to work with the truncated values in the following.
We recognize that the division by one to enforce the truncation is
actually overkill, but we stick with it for now, and shall tackle the
issue for PHP 7.3.
We back-port https://github.com/libgd/libgd/commit/dd48286 even though
we cannot come up with a regression test, because the erroneous
condition appears to be impossible to trigger.
We also parenthesize the inner ternary operation to avoid confusion.
We have to make sure to avoid alpha-blending issues by explicitly
switching to `gdEffectReplace` and to restore the old value afterwards.
This is a port of <https://github.com/libgd/libgd/commit/a7a7ece>.
PHP contained two different off-by-one errors, which are fixed here. First,
it created a buffer of size HOST_NAME_MAX, not adding space for a null
terminator. Second, it subtracted 1 from the size of that buffer when passing
its size to gethostname(), despite gethostname() expecting it to be a buffer
size including space for a terminating null byte, not a string length.
The WDDX specification[1] requires to serialize floats with a decimal
point, but `snprintf()` is locale-dependent and may use a decimal
comma. We fix that afterwards by replacing an eventual comma with a
point.
[1] <http://xml.coverpages.org/wddx0090-dtd-19980928.txt>
Directly fail unserialization when trying to acquire an r/R
reference to an UNDEF HT slot. Previously this left an UNDEF and
later deleted the index/key from the HT.
What actually caused the issue here is a combination of two
factors: First, the key deletion was performed using the hash API,
rather than the symtable API, such that the element was not actually
removed if it used an integral string key. Second, a subsequent
deletion operation, while collecting trailing UNDEF ranges, would
mark the element as available for reuse (leaving a corrupted HT
state with nNumOfElemnts > nNumUsed).
Fix this by failing early and dropping the deletion code.
