Instead of populating a hashtable of property names and then
directly serializing.
This has the advantage of a) detecting duplicate properties more
precisely and b) gives us the ability to discard values without
rewriting the serialization string after the fact for GH-5027.
This reverts commit b8ef7c35ab.
See bug #79031. The semantics of serialize locking aren't quite
correct right now, and the use of the lock in this particular
place makes us hit the issue in a common case. I'm reverting this
commit for PHP 7.4 and will try to fix this properly for PHP 8,
as I believe it will require ABI breakage.
Don't report EAGAIN/EWOULDBLOCK as errors for fwrite on
non-blocking socket streams. This matches behavior for fread,
as well as behavior for plain file streams.
Closes GH-5026.
* PHP-7.3:
Fixed bug #78910Fix#78878: Buffer underflow in bc_shift_addsub
Fix test
Fix#78862: link() silently truncates after a null byte on Windows
Fix#78863: DirectoryIterator class silently truncates after a null byte
Fix#78943: mail() may release string with refcount==1 twice
* PHP-7.2:
Fixed bug #78910Fix#78878: Buffer underflow in bc_shift_addsub
Fix test
Fix#78862: link() silently truncates after a null byte on Windows
Fix#78863: DirectoryIterator class silently truncates after a null byte
When normalizing tags to check whether they are contained in the set
of allowable tags, we must not strip slashes, unless they come
immediately after the opening `<`, or immediately before the closing
`>`.
If we're constructing extended-length paths (i.e. paths prefixed with
`\\?\`), we have to replace all forward slashes with backward slashes,
because the former are not supported by Windows for extended-length
paths.
The more efficient and likely cleaner alternative solution would be to
cater to this in `php_win32_ioutil_normalize_path_w()` by always
replacing forward slashes, but that might break existing code. It
might be sensible to change that for `master`, though.
For some reason FD 120 seems to exist on macos quite often, while
FD 12 did not... Let's try an even larger number, otherwise we
should just drop this test.
This stat property seems to be somewhat unreliable depending on the
filesystem. On Travis ARM64 CI a much larger payload is required
to get this value to increase.
This makes the stream opening actually fail, and avoids assertion
failures when we tokenize with EG(exception) set.
Also avoid throwing an additional warning after an exception has
already been thrown.
Nikita Popov