This loop can block for some minutes, theoretically. Practially
however, this is a 99% non issue for a normal use case. This is
required because read() is synchronous. The PHP streams API wants
to fill its internal buffers, therefore it might try to read some
more data than user has demanded. Also, for a case where we want
to read X bytes, but neither enough data nor EOF arrives, read()
will block until it could fill the buffer. If a counterpart station
runs slowly or delivers not all the data at once, read() would
still be waiting. If we quit too early, we possibly could loose
some data from the pipe. Thus it has to emulate the read()
behaviour, but obviously not completely, just to some grade.
Reading big data amount is for sure an issue on any platforms, it
depends on the pipe buffer size, which is controlled by the system.
On Windows, the buffer size seems to be way too small, which causes
buffer congestion and a dead lock. It is essential to read the pipe
descriptors simultaneously and possibly in the same order as the
opposite writes them.
Thus, this will work with smaller buffer data sizes passed through
pipes. As MSDN states, anonymous pipes don't support asynchronous
operations. Neither anonymous pipes do support select() as they are
not SOCKETs but file descriptors. Consequently - bigger data sizes
will need a better solution based on threads. However it is much
more expencive. Maybe a better solution could be exporting a part
of the internal doing as a userspace function which could perform
some kind of lookahead operation on the pipe descriptor.
This is just the first stone, depending on the user feedback we
might go for further improvements in this area.
The var hash now retains a reference to its elements, to ensure
that addresses are not reused.
Furthermore the var hash now only stores objects and references
and directly uses their pointer as key, thus making serialization
about two times faster.
So we can use it there as well...
For now I've retained the zend_smart_str_public.h header, though
it would probably be better to just move that one struct into
zend_types.h.
Now that zend_ulong is 64bit on 64bit platforms, it should be
sufficient to always use it, rather than supporting multiple
types.
API changes:
* _zend_print_unsigned_to_buf and _zend_print_signed_to_buf
no longer exist.
* smart_str(ing)_print_long and smart_str(ing)_print_unsigned
no longer exist.
* Instead of all these, zend_print_ulong_to_buf and
zend_print_long_to_buf should be used.
* smart_str_append_generic_ex no longer exists.
* smart_str(ing)_append_off_t(_ex) no longer exists, use
smart_str(ing)_append_long(_ex) instead.
smart_str_free_ex no longer exists, always use smart_str_free instead.
smart_str_alloc no longer requires a newlen variable to be in scope,
instead it returns the new length.
there are multiple issues with this code
- php_stream_read() returns an unsigned val, so is >= 0
- if it read less than sizeof(a) bytes, the function operates on garbage
- result->channels is an unsigned val, so >= 0
Till now the actualy length diff between the strings was under
circumstances returned. Whereby for a compare function only return
values of (1, 0, -1) make sense. Thus the old behavior isn't
present anymore, natcmp_ex now behaves as a standard compare function.
* PHP-5.6:
Updated UPGRADING for #38409
Updated NEWS for #38409
Added test case
Making ini parser typed - Added ZEND_INI_SCANNER_TYPED mode for parse_ini_string() and parse_ini_file() - Added NULL_NULL token to separate it from BOOL_FALSE and BOOL_TRUE - Added zend_ini_copy_typed_value() function for zval initialisation - Updated RETURN_TOKEN() to observe scanner_mode
Conflicts:
Zend/zend_ini_parser.y
Zend/zend_ini_scanner.c
- Added ZEND_INI_SCANNER_TYPED mode for parse_ini_string() and parse_ini_file()
- Added NULL_NULL token to separate it from BOOL_FALSE and BOOL_TRUE
- Added zend_ini_copy_typed_value() function for zval initialisation
- Updated RETURN_TOKEN() to observe scanner_mode