_php_stream_copy_to_stream_ex, when mmap is possible, doesn't check
if actually written bytes match read bytes.
Fix this (paranoid check) to be consistent with non mmap mode
Seems hard to add a unit test, as this rely on a full filesystem.
stream_get_line() could contain the delimiter string if that string
had more than one character. The bug manifested itself when a read on
the stream ended with part of the delimiter string and the read after
would start with the rest of the delimiter string; provided that
the data of first read did not complete the max length result of the
call to stream_get_line() with the partial delimiter used in that max
length return. In that case, the delimiter will still appear in
the result, divided in two subsequent return values. That is not a bug.
See <http://www.mail-archive.com/internals@lists.php.net/msg61325.html>
- Further fix for bug #60455 (stream_get_line misbehaves if EOF is not detected
together with the last read).
- Fixed bug #60817 (stream_get_line() reads from stream even when there is
already sufficient data buffered). stream_get_line() now behaves more like
fgets(), as is documented.
already fixed in trunk/5.3 and now merged onto 5.4 and a leak introduced in
fixing bug #61115. This better fix for #61115 fixes the leak (the inhibition
for deleting the context was too broad) and so prevents segfaults in new
circumstances (where the inhibition was not broad enough).
already fixed in trunk/5.3 and now merged onto 5.4 and a leak introduced in
fixing bug #61115. This better fix for #61115 fixes the leak (the inhibition
for deleting the context was too broad) and so prevents segfaults in new
circumstances (where the inhibition was not broad enough).
already fixed in trunk/5.3 and now merged onto 5.4 and a leak introduced in
fixing bug #61115. This better fix for #61115 fixes the leak (the inhibition
for deleting the context was too broad) and so prevents segfaults in new
circumstances (where the inhibition was not broad enough).
#NOTE: There is a very small possibility that this will further break
#extensions that access wrapper->{err_stack, err_count}. On PECL SVN, rar is the
#only one and it may leak memory after this. I say "further break" because
#extensions that do that are already broken (will segfault) under ZTS, which is
#why this patch is necessary.
#There was what I deem as tacit acceptance from 5.3/5.4 RMs on this.
#NOTE: There is a very small possibility that this will further break
#extensions that access wrapper->{err_stack, err_count}. On PECL SVN, rar is the
#only one and it may leak memory after this. I say "further break" because
#extensions that do that are already broken (will segfault) under ZTS, which is
#why this patch is necessary.
#There was what I deem as tacit acceptance from 5.3/5.4 RMs on this.
#NOTE: There is a very small possibility that this will further break
#extensions that access wrapper->{err_stack, err_count}. On PECL SVN, rar is the
#only one and it may leak memory after this. I say "further break" because
#extensions that do that are already broken (will segfault) under ZTS, which is
#why this patch is necessary.
#There was what I deem as tacit acceptance from 5.3/5.4 RMs on this.
together with the last read).
- Fixed bug #60817 (stream_get_line() reads from stream even when there is
already sufficient data buffered). stream_get_line() now behaves more like
fgets(), as is documented.
#withheld commit to 5.4
together with the last read).
- Fixed bug #60817 (stream_get_line() reads from stream even when there is
already sufficient data buffered). stream_get_line() now behaves more like
fgets(), as is documented.
#withheld commit to 5.4
