Add support for Solaris 11.4 openpty implementation.

Closes GH-6287.

Consolidate new union type ZPP macro names

They will now follow the canonical order of types. Older macros are
left intact due to maintaining BC.

Closes GH-6112

proc_open/openpty: DragonFlyBSD build fix.

Similarly to NetBSD emalloc-ish api had been introduced into libutil.

Closes GH-5960.

Add more argument types to stubs

Closes GH-5943

Support socketpairs in proc_open()

Closes GH-5777.

Remove proto comments from C files

Closes GH-5758

Implements an openpty wrapper for solaris based systems

This is only used by proc_open pty support, and as such declared
directly there.

Fix MSVC level 1 (severe) warnings

We fix (hopefully) all instances of:

* <https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4005>

Fix MSVC level 1 (severe) warnings

We fix (hopefully) all instances of:

* <https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4005>
* <https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4024>
* <https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4028>
* <https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4047>
* <https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4087>
* <https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4090>
* <https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4273>
* <https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4312>

`zend_llist_add_element()` and `zend_llist_prepend_element()` now
explicitly expect a *const* pointer.

We use the macro `ZEND_VOIDP()` instead of a `(void*)` cast to suppress
C4090; this should prevent accidential removal of the cast by
clarifying the intention, and makes it easier to remove the casts if
the issue[1] will be resolved sometime.

[1] <https://developercommunity.visualstudio.com/content/problem/390711/c-compiler-incorrect-propagation-of-const-qualifie.html>

show more ...

Build fix for newer versions of NetBSD.

its libutil contains newer conflicting apis as estrdup, emalloc.

Closes GH-5635

Tweak style and grammar in proc_open.c

Avoid compiler warnings in proc_open.c

We are getting a lot of compiler warnings when building on Appveyor CI (Windows).
Fix some of them.

Closes GH-5629

proc_open FreeBSD build fix

On this platform the needed header is different.

Closes GH-5623

Avoid duplicating the proc_open cleanup logic

Use a slightly ugly "goto unreachable" pattern to share this code,
so we don't have to duplicate cleanup logic for the success and
the f

Avoid duplicating the proc_open cleanup logic

Use a slightly ugly "goto unreachable" pattern to share this code,
so we don't have to duplicate cleanup logic for the success and
the failure cases.

show more ...

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 r

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.

show more ...

Don't leak memory if wrong resource type is passed to proc_open

proc_open can accept stream resources in the descriptorspec, like this:

proc_open("command", array(0 => $resource

Don't leak memory if wrong resource type is passed to proc_open

proc_open can accept stream resources in the descriptorspec, like this:

proc_open("command", array(0 => $resource), $pipes);

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.

show more ...

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 th

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.

show more ...

Use zend_zval_type_name() API where possible

Rather than zend_get_type_by_const(Z_TYPE_P()).

Extract one more function from proc_open() implementation

Clean up proc_open() implementation

Closes GH-5507.

Remove is_persistent flag from proc_open implementation

We don't support persistent proc_open handles and have no plan
to suppor them. The mixture of persistent and non-persistent
al

Remove is_persistent flag from proc_open implementation

We don't support persistent proc_open handles and have no plan
to suppor them. The mixture of persistent and non-persistent
allocations functions in this code is somewhat confusing to read.

show more ...

Improve a last couple of argument error messages

Closes GH-5404

Improve argument error messages in ext/standard

Closes GH-5198

Make quoting of cmd execution functions consistent

While the `$command` passed to `proc_open()` had to be wrapped in
double-quotes manually, that was implicitly done for all other
pr

Make quoting of cmd execution functions consistent

While the `$command` passed to `proc_open()` had to be wrapped in
double-quotes manually, that was implicitly done for all other
program execution functions. This could easily introduce bugs and
even security issues when switching from one to another program
execution function.

Furthermore we ensure that the additional quotes are always
unwrapped regardless of what is passed as `$command` by passing
the `/s` flag to cmd.exe. As it was, `shell_exec('path with
spaces/program.exe')` did execute program.exe, but adding an
argument (`shell_exec('path with spaces/program.exe -h)`) failed
to execute program.exe, because cmd.exe stripped the additional
quotes.

While these changes obviously can cause BC breaks, we feel that in
the long run the benefits of having consistent behavior for all
program execution functions outweighs the drawbacks of potentially
breaking some code now.

show more ...

Create a new console for each test worker on Windows

The primary motivation to have each test worker running its own console
is to allow the windows_mb_path tests to run in parallel. A

Create a new console for each test worker on Windows

The primary motivation to have each test worker running its own console
is to allow the windows_mb_path tests to run in parallel. A nice side
effect is that this also prevents changing the code page of the
tester's console window (which can even cause its font to be changed).

To be able to do so, we introduce the `create_new_console` option for
`proc_open()`, which might occasionally be useful for other purposes
than testing.

show more ...

Make error messages more consistent by fixing capitalization

Closes GH-5066 As a first step, let's capitalize their initial letter when it is applicable.