Since the member is not used in `OnUpdateEol()` that's not really an
issue, but still it's confusing to apparently have two INI settings
targeting the same member.
Dmitry Stogov [Fri, 15 May 2020 07:44:14 +0000 (10:44 +0300)]
Merge branch 'master' of git.php.net:php-src
* 'master' of git.php.net:php-src:
fixed typo of bug id (#79599)
master doesn't been affected since we are not passing errcontext now
Fixed bug #97599 (coredump in set_error_handler)
Fix #79557: extension_dir = ./ext now use current directory for base
Fix #79596: MySQL FLOAT truncates to int some locales
[ci skip] Fix NEWS
Xinchen Hui [Fri, 15 May 2020 07:36:51 +0000 (15:36 +0800)]
Merge branch 'PHP-7.4' of git.php.net:/php-src into PHP-7.4
* 'PHP-7.4' of git.php.net:/php-src:
Fix #79557: extension_dir = ./ext now use current directory for base
Fix #79596: MySQL FLOAT truncates to int some locales
[ci skip] Fix NEWS
Fix #79557: extension_dir = ./ext now use current directory for base
For some reason, `ImageLoad()` fails to load images with a relative
path starting with `.\` or `./`. We work around this issue by
stripping those leading characters.
We add the missing release dates, the NEWS regarding the latest CVE
fixes, and move the entry for bug #79536 to 7.4.7 because it didn't
make it into 7.4.6.
Alex Dowad [Tue, 12 May 2020 06:43:29 +0000 (08:43 +0200)]
Further refactoring of proc_open.c
This time a number of comments have been added to make it easy for new devs to understand
what is going on. Also adjusted error message to use colons rather than dashes.
Previously, if a resource which was *not* of type "stream" was passed, proc_open would
return without freeing dynamically allocated memory. It's fixed now.
Alex Dowad [Sun, 3 May 2020 15:54:06 +0000 (17:54 +0200)]
Add PTY support to proc_open (again after 16 long years)
Back in 2004, a feature was added to proc_open which allowed it to open a PTY,
connecting specific FDs in the child process to the slave end of the PTY and returning
the master end of the PTY (wrapped as a PHP stream) in the `$pipes` array. However,
this feature was disabled just about a month later. Little information is available
about why this was done, but from talking to the original implementer, it seems there
were portability problems with some rare flavors of Unix.
Re-enable this feature with a simplified implementation which uses openpty(). No
attempt is made to support PTYs if the platform does not have openpty(). The configure
script checks if linking with -lutil is necessary to use openpty(), but if anything
else is required, like including some special header or linking with some other library,
PTY support will be disabled.
The original PTY support for proc_open automatically daemonized the child process
(disassociating it from the TTY session and process group of the parent). However,
I don't think this is a good idea. Just because a user opens a child process in a
PTY, it doesn't mean they want it to continue running even when the parent process
is killed. Of course, if the child process is some kind of server, it will likely
daemonize itself; but we have no reason to preempt that decision.
It turns out that since 2015, there has been one test case for PTY support in
proc_open() in the test suite. This test was added in GitHub PR #1588
(https://github.com/php/php-src/pull/1588). That PR mentioned that the PHP
binary in the Debian/Ubuntu repositories is patched to *enable* PTY support. Checking
the Debian PHP repository (https://salsa.debian.org/php-team/php.git) shows that this
is still true. Debian's patch does not modify the implementation from 2004 in any
way; it just removes the #if 0 line which disables it.
Naturally, the test case is skipped if PTY support is not enabled. This means that ever
since it was added, every test run against the 'vanilla' PHP codebase has skipped it.
Interestingly, the test case which was added in 2015 fails on my Linux Mint PC... both
with this simplified implementation *and* when enabling the original implementation.
Investigation reveals the reason: when the child process using the slave end of the
PTY exits and its FDs are all closed, and all buffered data is read from the master
end of the PTY, any further attempt to read from the master end fails with EIO. The
test case seems to expect that reading from the master end will always return an
empty string if no data is available.
Likely this is because PHP's fread() was updated to report errors from the underlying
system calls only recently.
One way out of this dilemma: IF at least one FD referring to the slave end of the PTY is
kept open *in the parent process*, the failure with EIO will not occur even after the child
process exits. However, that would raise another issue: we would need a way to ensure the FD
will be closed eventually in long-running programs.
Another discovery made while testing this code is that fread() does not always return
all the data written to the slave end of the PTY in a single call, even if the data was
written with a single syscall and it is only a few bytes long.
Specifically, when the child process in the test case writes "foo\n" to the PTY, the parent
sometimes receives "foo" (3 bytes) and sometimes "foo\r\n" (5 bytes). (The "\r" is from the
TTY line discipline converting "\n" to "\r\n".) A second call to fread() does return the
remaining bytes, though sometimes all the data is read in the first call, and by the time
the second call is made, the child process has already exited. It seems that liberal use
of the @ operator is needed when using fread() on pipes.
Thanks to Nikita Popov for suggesting that we should just use openpty() rather than
grantpt(), unlockpt(), etc.
Gerard Roche [Wed, 13 May 2020 18:57:54 +0000 (19:57 +0100)]
Fix lcov genhtml: ERROR: cannot read [file]
lcov is emitting several errors for generated regex files that have no code
coverage data. The fix is to add the files to the lcov exlusion list.
This is not an issue for CI because it uses gcovr to generate code coverage.
The errors:
Processing ext/date/lib/parse_date.gcda
geninfo: WARNING: could not open /home/code/vendor/php/php-src/parse_date.re
geninfo: WARNING: could not open /home/code/vendor/php/php-src/<stdout>
geninfo: WARNING: some exclusion markers may be ignored
Processing ext/date/lib/parse_tz.gcda
Processing ext/date/lib/tm2unixtime.gcda
Processing ext/date/lib/parse_iso_intervals.gcda
geninfo: WARNING: could not open /home/code/vendor/php/php-src/<stdout>
geninfo: WARNING: could not open /home/code/vendor/php/php-src/parse_iso_intervals.re
geninfo: WARNING: some exclusion markers may be ignored
...
genhtml: ERROR: cannot read /home/code/vendor/php/php-src/parse_date.re
Processing file /home/code/vendor/php/php-src/parse_date.re
make: *** [Makefile:443: lcov-html] Error 2
To solve bug #70886, the test uses random keys to prevent collisions;
however, this is not guaranteed, and as such it may even collide with
other tests in the shmop test suite. The proper solution would be to
use a single key (which could be randomly generated), but to actually
`shmop_close()` after each `shmop_delete()`. This would, however, not
work on Windows due to bug #65987. Therefore we use three different
keys for now.
Nikita Popov [Wed, 13 May 2020 12:46:15 +0000 (14:46 +0200)]
Rename zend_zval_get_type() API
We have a bunch of APIs for getting type names and it's sometimes
hard to keep them apart ... make it clear that this is the one
you definitely do not want to use.