Extensions may (and do) write to stderr in mshutdown and similar. In
the best case, with the stderr stream closed, it's just swallowed.
However, some libraries will do things like try to detect color, and
these will outright fail and cause an error path to be taken.
Extensions may (and do) write to stderr in mshutdown and similar. In
the best case, with the stderr stream closed, it's just swallowed.
However, some libraries will do things like try to detect color, and
these will outright fail and cause an error path to be taken.
Extensions may (and do) write to stderr in mshutdown and similar. In
the best case, with the stderr stream closed, it's just swallowed.
However, some libraries will do things like try to detect color, and
these will outright fail and cause an error path to be taken.
This is a stepping stone in converting more pairs of ``char*`` and ``size_t`` to ``zend_string*`` across the CLI SAPI.
Also amend the CLI SAPI test setup to output it's content when it crashes/errors so that one can debug ASAN/UBSAN/MSAN violations.
Drive-by MSAN fix.
Co-authored-by: Arnaud Le Blanc <arnaud.lb@gmail.com>
sapi\cli\php_cli_server.c(2637): warning C4133: 'function': incompatible types - from 'zend_result (__cdecl *)(void *,php_socket_t,int)' to 'int (__cdecl *)(void *,php_socket_t,int)'
Probably a good idea to make GCC complain about these sort of issues too
Requiring all internal classes (including those from 3rd-party
extensions) to implement Stringable if they provide __toString()
is too error prone. Case in point, our _ZendTestClass test class
was not doing so, resulting in preloading test failures after
recent changes.
Instead we automatically implement Stringable, the same as we do
for userland classes. We still allow explicit implementations,
but ignore them (normally they would result in an error due to
duplicate interface implementation). Finally, we need to be
careful about not trying to implement Stringable on Stringable
itself.
In some cases this changes the interface order, in particular the
automatic Stringable implementation will now come first.
- for packed arrays we store just an array of zvals without keys.
- the elements of packed array are accessible throuf as ht->arPacked[i]
instead of ht->arData[i]
- in addition to general ZEND_HASH_FOREACH_* macros, we introduced similar
familied for packed (ZEND_HASH_PACKED_FORECH_*) and real hashes
(ZEND_HASH_MAP_FOREACH_*)
- introduced an additional family of macros to access elements of array
(packed or real hashes) ZEND_ARRAY_ELEMET_SIZE, ZEND_ARRAY_ELEMET_EX,
ZEND_ARRAY_ELEMET, ZEND_ARRAY_NEXT_ELEMENT, ZEND_ARRAY_PREV_ELEMENT
- zend_hash_minmax() prototype was changed to compare only values
Because of smaller data set, this patch may show performance improvement
on some apps and benchmarks that use packed arrays. (~1% on PHP-Parser)
TODO:
- sapi/phpdbg needs special support for packed arrays (WATCH_ON_BUCKET).
- zend_hash_sort_ex() may require converting packed arrays to hash.
As a followup to f34114b1fb print
the contents of arrays rather than just a generic "Array" marker.
Also drop the truncation on strings. As we no longer resolve
constants, there should be less concerns about printing very
large strings here. If someone thought it was a good idea to use
a 10k character strings as a default value in code, then it should
be fine for us to print it in reflection as well.
We need to run the full `php_cli_server_request_shutdown()` in case of
failing `php_cli_server_request_startup()`.
Patch contributed by @cataphract.
Closes GH-7322.
While our HTTP parser supports upgrade requests, the code using it does
not. Since upgrade requests are only valid for HTTP/1.1 and we neither
support any higher version, nor HTTPS yet, we do not exit early in case
of such requests, i.e. we ignore them, what is allowed by the specs.
We keep the supporting code in case we can meaningfully support upgrade
requests in the future.
Closes GH-7316.
