Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84637
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
Sender: Michael Wallner <mike.php.net@gmail.com>
Message-ID: <55019901.3090107@php.net>
Date: Thu, 12 Mar 2015 14:47:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Umberto Salsi <salsi@icosaedro.it>, internals@lists.php.net
References: <2D.74.42021.0A491055@pb1.pair.com>
In-Reply-To: <2D.74.42021.0A491055@pb1.pair.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] php_stream_read(...) may return less than expected
From: mike@php.net (Michael Wallner)

On 12/03/15 14:28, Umberto Salsi wrote:
> Hi all,
> I'm not a PHP internals developer, but this might be a bug spread here and
> there in the source. This coding pattern:
> 
> if(php_stream_read(..., n) != n){
>     php_error_docref(NULL TSRMLS_CC, E_SOMETHING, "Read error!");
> 
> seems wrong to me because there might be streams that returns less than
> n bytes at once. When exactly n bytes are expected, not more not less,
> a function similar to this one should be used instead:
> 
> int php_stream_read_fully(..., int n){
> 	continue calling php_stream_read() until exactly n bytes are
>     collected, or a premature EOF, or I/O error
> }
> 
> I ran into this issue passing a custom stream to getimagesize():
> 
> getimagesize("myprotocol://");
> 
> where myprotocol:// may, in some situations, return less bytes than
> expected (see the http://php.net/manual/en/class.streamwrapper.php
> wrapper class, stream_read() method). Looking at the implementation of
> this function in ext/standard/image.c, I just found the pattern above.
> If this is really a bug, many other functions might be affected.

Why does your stream behave non-blocking by default? Unless explicitly
stated, those callees probably expect a blocking stream.


-- 
Regards,
Mike