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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
