php_check_open_basedir() expects a local filesystem path,
but we're handing it a `glob://...` URI instead.
Move the check to after the path trim so that we're checking
a meaningful pathspec.
As fcgi_request is an opaque struct as of PHP 7, expose a new API
function fcgi_end() which does fcgi_flush() with end=1 and checks/
sets the ->ended flag.
"closed" refers to whether FCGI_END_REQUEST has been sent, while
the "close" operation does something entirely different. It gets
extra confusing when fcgi_is_closed() does not actually return
fcgi_request.closed...
vs(tr)pprintf is now implemented in Zend on top of
printf_to_smart_str(int), which is provided as a utility function.
This allows us to efficiently printf to the end of a smart string.
It's annoying that in Zend you have to use zend_strpprintf instead
of strpprintf, while in PHP you have to use strpprintf instead of
zend_strpprintf.
Make zend_s(tr)pprintf always available and keep s(tr)pprintf as
macro aliases.
If PHP CLI is used with programs with no Unicode support, the default
PHP console codepage might cause backward incompatible behaviors. This
is solved with this patch by separating the handling of I/O codepage.
As per https://wiki.php.net/rfc/default_encoding input_encodnig and
output_encoding are centralized INI settings, so they're used for the
purpose of adjusting the codepage. This gives user the ability to use
UTF-8 internally, while letting the system API to convert the output
to a compatible codepage. This also might solve the font issues on
systems without good true type support.
Note, that there no change to the default behavior - if input and
output encoding are not set, which is the default case, the default
charset applies to both console input and output. The patch is just
a compilment to the backward compatibility, not more and not less.
If this does not break the Unix system somehow, I'll be amazed. This should get most of it out, apologies for any errors this may cause on non-Windows ends which I cannot test atm.
